Dmix and non SND_PCM_TYPE_HW slaves

Dmix and non SND_PCM_TYPE_HW slaves

[sameer.kittur]

[-- Attachment #1: Type: text/html, Size: 1337 bytes --]

Re: Dmix and non SND_PCM_TYPE_HW slaves

[Jaroslav Kysela]

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.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
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_id=7628&alloc_id=16845&op=click

Re: Dmix and non SND_PCM_TYPE_HW slaves

[Takashi Iwai]

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.


Takashi


-------------------------------------------------------
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_id=7628&alloc_id=16845&op=click

Re: Dmix and non SND_PCM_TYPE_HW slaves

[Jaroslav Kysela]

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.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
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_id=7628&alloc_id=16845&op=click

Re: Dmix and non SND_PCM_TYPE_HW slaves

[Takashi Iwai]

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.


Takashi





-------------------------------------------------------
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_id=7628&alloc_id=16845&op=click

Re: Dmix and non SND_PCM_TYPE_HW slaves

[Jaroslav Kysela]

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.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs


-------------------------------------------------------
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_id=7628&alloc_id=16845&op=click

Re: Dmix and non SND_PCM_TYPE_HW slaves

[Takashi Iwai]

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 :)


Takashi


-------------------------------------------------------
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_id=7628&alloc_id=16845&op=click

Re: Dmix and non SND_PCM_TYPE_HW slaves

[James Courtier-Dutton]

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?
> 
> Thanks,
> Sameer.
> 

Why would you want to do this?
The purpose of dmix is to simply work around the limitation of the hardware.
If you want some other purpose, I would suggest using a sound server 
like arts or a different approach altogether like using jackd

James



-------------------------------------------------------
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_id=7628&alloc_id=16845&op=click

Re: Dmix and non SND_PCM_TYPE_HW slaves

[Adam Tlałka]

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

Re: Dmix and non SND_PCM_TYPE_HW slaves

[Takashi Iwai]

At Wed, 16 Nov 2005 19:03:54 +0100,
Adam Tlałka wrote:
> 
> 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.

The situation wouldn't change even if implemented in the kernel.
Basically the RT process must win, regardless of user or kernel space
jobs (except for very critical ones like interrupt handling).
It's just a matter of RT-task priority.


Takashi


-------------------------------------------------------
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

Re: Dmix and non SND_PCM_TYPE_HW slaves

[sameer.kittur]

[-- Attachment #1: Type: text/html, Size: 2677 bytes --]

Re: Dmix and non SND_PCM_TYPE_HW slaves

[Adam Tlałka]

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

> At Wed, 16 Nov 2005 19:03:54 +0100,
> Adam Tlałka wrote:
>>
>> 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.
>
> The situation wouldn't change even if implemented in the kernel.
> Basically the RT process must win, regardless of user or kernel space
> jobs (except for very critical ones like interrupt handling).

Thats true and sound card programming or data transfer preparing is a very
critical task if we talking about proper timing. Sometimes it's needed to
interrupt buffers update kernel function. Of course it is an interrupt  
handler
role. But mixing is a time critical function too.

> It's just a matter of RT-task priority.

Yes and if we will have more RT task we must tune it carefully.:-)

Anyway if this all is done in a lib what about dynamic input/output mode  
change.
Can I switch from 2-speakers to 5.1 speakers or headphone mode or insert
particular sound filter just using some control panel or app without
need of restarting or specially recompile my sound app?

Is this kind of functionality possible with current model without
rewritting many applications?

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

Re: Dmix and non SND_PCM_TYPE_HW slaves

[Takashi Iwai]

At Thu, 17 Nov 2005 11:18:30 +0100,
Adam Tlałka wrote:
> 
> Dnia 16-11-2005 o 19:23:37 Takashi Iwai <tiwai@suse.de> napisał:
> 
> > At Wed, 16 Nov 2005 19:03:54 +0100,
> > Adam Tlałka wrote:
> >>
> >> 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.
> >
> > The situation wouldn't change even if implemented in the kernel.
> > Basically the RT process must win, regardless of user or kernel space
> > jobs (except for very critical ones like interrupt handling).
> 
> Thats true and sound card programming or data transfer preparing is a very
> critical task if we talking about proper timing. Sometimes it's needed to
> interrupt buffers update kernel function. Of course it is an interrupt  
> handler
> role. But mixing is a time critical function too.
> 
> > It's just a matter of RT-task priority.
> 
> Yes and if we will have more RT task we must tune it carefully.:-)

Yes, and my point above is that it's samely difficult to get it right
even if you do it in the kernel.  For example, the soft irq is just a
thread in RT kernel.  The hard irq is no option.  Doing such a job in
the hardirq is nonsense.

> Anyway if this all is done in a lib what about dynamic input/output mode  
> change.
> Can I switch from 2-speakers to 5.1 speakers or headphone mode or insert
> particular sound filter just using some control panel or app without
> need of restarting or specially recompile my sound app?
> 
> Is this kind of functionality possible with current model without
> rewritting many applications?

A good question.  Currently, no.  The h/w configuration is assumed to
be constant during operation.  However, in theory, it's possible even
without restarting/rewriting apps under certain conditions:

- The PCM hw parameters are kept before and after changing h/w
  configuration so that apps don't have to care about the changes in
  the outside world.  That is, the app has to do either 2 or 6
  channels from beginning and not changed at all regardless of h/w
  configuration.  The channels will be downmixed or expanded
  appropriately in alsa-lib.

- The app handles errors, specially XRUN, properly.


Takashi


-------------------------------------------------------
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

Re: Dmix and non SND_PCM_TYPE_HW slaves

[Adam Tlałka]

Dnia 16-11-2005 o 18:34:05 James Courtier-Dutton <James@superbug.co.uk>  
napisał:

> 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?
>>  Thanks,
>> Sameer.
>>
>
> Why would you want to do this?
> The purpose of dmix is to simply work around the limitation of the  
> hardware.
> If you want some other purpose, I would suggest using a sound server  
> like arts or a different approach altogether like using jackd

He just want to use ALSA :-).
It seems impossible to use default dmix output in case of non hardware  
slave
or non DMA ring buffer hw device so for some people dmix is a solution
but for some of them it is not. Also there is a problem with some OSS apps.

Using jackd on top of ALSA is just wasting resorces. If jackd is so good  
then it should
work directly on top of device driver. ALSA lib is not needed in this case.

But jackd needs patched kernel, RT priority and jackd-aware applications.
So it is not easy solution anyway. If you are using just a few apps which  
you
can patch then no problem here. But in case of workstation and WWW  
browsers,
Flash, Java, Realplayer and some other proprietary apps with no sources  
(games ;-))
it is really hard. aoss is far from perfect and some apps disable use of  
LD_PRELOAD
so this method is sometimes unusable, kernel OSS emulation is not complete  
and
not mixing at all (it needs kernel mixing IMHO which is not politically  
correct :-)).

So where to go - commercial OSS software is doing input/output mixing in  
kernel
and for private use is free of charge. There are some limitations of course
but its normal.

 From my point of view ALSA API is not much better then OSS.
There are some weak points in both. Programming sound in ALSA needs a  
little bit
more lines of code then in OSS case. Lack of good doc is a very bad  
situaction.

You can use many methods to access sound card through ALSA: normal  
read/write,
memory mapping, calbacks and some mixed modes. I just can't find a doc  
stating
clearly which mode is the best one in which situaction and how to properly  
use it.
For example I tested aoss with callbacks but because callbacks use signals  
which
are disabled by some apps so we have no sound in this case.

Some programs work better with OSS aoss emulation then while directly  
using ALSA
which means that their ALSA code is bad. Lack of good explanation of  
proper API
usage is the reason. Source doxygen means not much for me - I know that  
this parameter
is int and mean period size for example but what period size to use and in  
which case.
Examples are rather simple and often not explaining what to do in error  
situactions.
Creators of ALSA should made some good docs - users just don't know enough  
to point out
important things. Users Wiki pages are nice but they often present results  
of user experiments
and no real explanation.

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