>> aserver doesn't provide a frame count to the client client telling it
>> how much to do. when the client returns from poll(2), it can find out
>> how much space/data is available, but at this time, that has no direct
>> correlation with how much it should actually process. i can't see that
>> it ever would unless you come up with a whole new set of fake ALSA PCM
>> devices in which the relevant alsa-lib calls meet this requirement.
>
>I don't agree here. If application doesn't send sufficient count
>of frames, then xrun situation occurs. An arbiter removes the
>execution list.
how can the application *know* the correct count? there is no ALSA API
call that will reveal this unless the "share" PCM device has different
semantics than all the others.
>Well, I'm only trying to determine, if your code is really a better
>solution. For me, it seems that it will work with the same overhead as
>our idea. You have distributed arbiter code, we work with a compact
>arbiter.
i guess i'm no longer sure what you meant by "arbiter". i was assuming
you mean something that handled format conversion issues. now it
appears that it means something different, more like what i would call
a "server".
>> lets take the scheme above and make it have 2 producers and one destination:
>>
>> producer1 -> [ whatever ] -+
>> |-> consumer
>> producer2 -> [ whatever ] -+
>>
>> producer1 and producer2 will not run in sample sync unless something
>> causes them to be executed synchronously. i've seen nothing in aserver
>> that provides for synchronous exection. having them both return from
>
>Yes, aserver takes care about shm only. The real kernel is the share
>or mix (non-existent) plugin.
but that plugin exists for each client that has the PCM device
open. it therefore cannot ensure synchronous execution without doing
exactly the kind of IPC that JACK does.
>> poll isn't adequate unless upon return from poll they are guaranteed
>> to process the same number of frames *and* its also guaranteed that
>> the consumer will do nothing until both producers are finished.
>
>Because the share plugin works with one destination ring buffer, then
>these requirements are met. The synchronization time frame is given by
>size of the destination ring buffer.
no. thats not necessarily the synchronization time frame. i could be
using a ring buffer of 5MB, but that doesn't mean that each client
should be filling it each time we execute them. if the ring buffer
size is the same size as the number of frames per-client invocation,
why use a ringbuffer? it sounds as if you are in fact saying that the
various existing ALSA API calls will have different semantics for the
share device, in that its a device with a single period per buffer,
and the calls to find out how much space/data is available always
indicate a single period's worth. thats pretty different than existing
PCM devices, where i could discover that there are 2 period's worth of
data waiting to be processed, or whatever.
>> the JACK engine orders all clients in the correct execution order (and
>> it picks an order if there is no correct execution order). it
>> dynamically reorders the execution chain whenever the processing graph
>> is changed. note that it also does not involve a context switch back
>> to the server every time a client is finished - clients are chained so
>
>Really? How you can do it? I think that the scenario for mentioned 2
>produces and one consumer would be like:
>
> 1st csw: consumer
> 2nd csw: producer1 callback
> 3rd csw: consumer
> 4th csw: producer2 callback
Nope. Its as you stated for ALSA, almost:
jack server (woken by a special client/driver, which has decided its
time to do something)
1st csw: producer1
2nd csw: producer2
3rd csw: consumer
jack server (tells client/driver that we did something)
of course, if the consumer *is* the driver (e.g. the driver is the one
i wrote, that uses ALSA to do audio i/o, and there is I/O to a driver
port), then the 3rd csw doesn't happen.
BTW, I've never found any code in ALSA to do anything like this. JACK,
for all its gaps right now, does actually do this. In addition, the
number of switches has nothing to do with the PCM device set up.
Further, this:
> 1st csw: producer1
> 2nd csw: producer2
> 3rd csw: consumer, waken up in regular time intervals
is not satisfactory. for low latency work, the producers and the
consumer have to be operating synchronously. its not ok for the
consumer to wake up periodically and process whatever is waiting. the
output of the producers has to be handled by the consumer on the same
"cycle" as they produced it. otherwise, its easy to draw graphs which
stall periodically.
>Well, I think that you noted two opposite ways now. You don't want to
>have an arbiter, and you are using an arbiter code to remove bad clients.
this is just a terminology issue. as i noted, i didn't understand what
you meant by "arbiter".
>>From my point of view: you simplified the communication, using one stream
>format and fixed data amounts, but the final result is and will be same.
is that the attitude you want to take towards the relationship between
any two API's ? OSS and ALSA for example? after all, there is nothing
that can't be done with OSS that can be done with ALSA, its just that
its a lot harder in some cases to do it with OSS. Does that mean that
ALSA is of no use? Of course not.
the JACK/callback style API makes producing collaborating audio
applications simple, and robust. it ensures that they use the correct
program design to allow them to collaborate. adding, implementing
and/or finishing the "share" PCM device doesn't do this. it allows
applications to continue to be written in a way that is based on
blocking read/write, and this cannot be used for low latency
synchronous execution of multiple apps sharing a device or data. i
mean, thats the whole point right? the whole claim is that
applications have no idea what kind of PCM device they are writing to!
my point is that this design is wrong for low latency sample sync. not
just wrong, but actually unworkable.
i'm sorry to keep repeating this, but it doesn't seem to be clear. i
have only passing interest in yet another "sound server" that does
mostly just what esd does, except cleaner and better engineered. my
interest is in allowing applications to in low latency sample sync
situations, and i see nothing in the source, docs or your discussion
that suggests that the ALSA API will facilitate this other than by
providing a HAL.
what i *do* see is a good design for a shared sound server, but given
that working versions of these exist already and they don't address
the needs of musicians and audio/recording engineers, this doesn't
help a great deal. it would still be a good thing to have, but its not
providing what Rewire or CoreAudio provide.
--p
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
