On 01/21/2010 03:28 PM, torbenh wrote:
> On Thu, Jan 21, 2010 at 07:48:20AM -0500, Paul Coccoli wrote:
>> On Thu, Jan 21, 2010 at 6:37 AM, torbenh <torbenh@email-addr-hidden> wrote:
>>> well.. the real problems are a bit deeper.
>>> and not really touched be any example clients.
>>>
>>> you need to have lockfree access to the note sequence.
>>> while still being able to manipulate it from the gui thread.
>>>
>>> several approaches to achieve this are possible. and it depends a bit on
>>> taste and the app to select them.
>>>
>>> but the major part of complexity lies here.
>>>
>> I assume std::priority_queue can't be used, because it uses a
>> std::vector which will, under the covers, allocate memory from the
>> stack.
>
> you can specify an Allocator for most STL containers.
> but i am not aware of anybody using them with an RT safe allocator.
> might be possible.
>
> but the allocator is not the problem.
> its lockfree access.
>
>> It would be interesting to try to write an STL queue-like container
>> with an allocator that grabbed chunks of memory from a pool in an
>> RT-safe way. Maybe via message-passing over a ringbuffer? Anyone
>> seen/have such a thing?
>
> dunno... i never looked at implementing an allocator.
> shouldnt be that hard.
>
> but as stated, this is still a trivial part of the problem.
I think that Harry's question was more about time as he rephrased it in his 2nd
post, than about event queuing, although this is of course linked.
But in regard to time, what about Beat-Bar-Tick which seems to be important to him?
How many applications support (set or handle) the Beat-Bar-Tick related jack
transport position fields?
In general, how reliable are these fields?
-- Olivier _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@email-addr-hidden http://lists.linuxaudio.org/listinfo/linux-audio-devReceived on Sat Jan 23 00:15:02 2010
This archive was generated by hypermail 2.1.8 : Sat Jan 23 2010 - 00:15:02 EET