Re: Dmix and non SND_PCM_TYPE_HW slaves

["Adam Tlałka" <atlka@pg.gda.pl>]

Dnia 16-11-2005 o 16:23:36 Takashi Iwai <tiwai@suse.de> napisał:

> At Wed, 16 Nov 2005 16:14:31 +0100 (CET),
> Jaroslav Kysela wrote:
>>
>> On Wed, 16 Nov 2005, Takashi Iwai wrote:
>>
>> > At Wed, 16 Nov 2005 15:24:26 +0100 (CET),
>> > Jaroslav Kysela wrote:
>> > >
>> > > On Tue, 15 Nov 2005, Takashi Iwai wrote:
>> > >
>> > > > At Tue, 15 Nov 2005 08:39:06 +0100 (CET),
>> > > > Jaroslav wrote:
>> > > > >
>> > > > > On Tue, 15 Nov 2005 sameer.kittur@flextronicssoftware.com wrote:
>> > > > >
>> > > > > > Hi all,
>> > > > > >
>> > > > > >     Is there a reason why Dmix cannot use a non  
>> SND_PCM_TYPE_HW slave? Is
>> > > > > > there no way to re-direct the Dmix output to another plugin  
>> or an
>> > > > > > external I/O or a filter plugin?
>> > > > >
>> > > > > It's impossible without massive changes to the dmix code and  
>> structure.
>> > > > > Dmix uses too much driver specific things like the PCM timer,  
>> passing PCM
>> > > > > device file-descriptor among applications etc. Also, the  
>> latency can be
>> > > > > much worse when the dmix plugin will use only SHM ring buffer  
>> or so.
>> > > >
>> > > > Actually, it's difficult to apply the current dmix model to a
>> > > > (user-space) driver without DMA like bluez.  We need to gather the
>> > > > data from all clients and send only once to the hardware in such a
>> > > > case.  So, the solution with a sound server looks most  
>> appropriate.
>> > >
>> > > It's not so difficult, but extra double buffering will be added  
>> between
>> > > producer and consumer, so the latency increases min. twice.
>> >
>> > Hmm, but still this doesn't work well.  Remember that the data chunk
>> > once tranferred cannot be modified any longer.  Hence, to get a low
>> > latency, the buffer must be sent just before the active update.
>> > In the best case, we may have only 2 periods in practice.
>> >
>> > This would work if a server process runs in a high task priority, but
>> > not for the models with parallel accessses like dmix.
>>
>> I meant a daemon with RT priority which will "emulate" DMA.
>
> I see.  Then, surely it's not difficult :)

Maybe but again problem may rise if we have more RT apps in the system.
If kernel treats all RT apps same way we will have problems anyway.
Only true solution is doing this in the kernel so it knows which latency
is needed and can woke up proper app in the proper time.

Sorry to say that but under high load and while big apps rescheduling is  
done
ALSA is doing rather poorly. Without kernel support it can't be resolved
and current approach leads to dead end IMHO.

Regards
-- 
Adam Tlałka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id\x16845&op=click