status pointer's problem with dmix.

status pointer's problem with dmix.

[James Courtier-Dutton]

Output from sending stereo sound to the "dmix" device.
bash-2.05b# cat status
state: RUNNING
trigger_time: 1063822024.640173000
tstamp      : 1063822060.456968000
delay       : -1719463
avail       : 1731463
avail_max   : 1731463
-----
hw_ptr      : 1719463
appl_ptr    : 0
bash-2.05b#

Output from sending stereo sound to the "front" device.
bash-2.05b# cat status
state: RUNNING
trigger_time: 1063823309.038609000
tstamp      : 1063823320.869677000
delay       : 14161
avail       : 2223
avail_max   : 3586
-----
hw_ptr      : 567983
appl_ptr    : 582144

As you can see, the "front" device acts correctly, with all the pointers 
acting as they should.
But with "dmix", all the pointers are wrong.
This is particularly problematic for me, as I need a properly 
functioning "delay" value for my application.

This is using alsa from 2.6test5 kernel.

Cheers
James



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[Takashi Iwai]

At Wed, 17 Sep 2003 19:33:29 +0100,
James Courtier-Dutton wrote:
> 
> Output from sending stereo sound to the "dmix" device.
> bash-2.05b# cat status
> state: RUNNING
> trigger_time: 1063822024.640173000
> tstamp      : 1063822060.456968000
> delay       : -1719463
> avail       : 1731463
> avail_max   : 1731463
> -----
> hw_ptr      : 1719463
> appl_ptr    : 0
> bash-2.05b#
> 
> Output from sending stereo sound to the "front" device.
> bash-2.05b# cat status
> state: RUNNING
> trigger_time: 1063823309.038609000
> tstamp      : 1063823320.869677000
> delay       : 14161
> avail       : 2223
> avail_max   : 3586
> -----
> hw_ptr      : 567983
> appl_ptr    : 582144
> 
> As you can see, the "front" device acts correctly, with all the pointers 
> acting as they should.
> But with "dmix", all the pointers are wrong.
> This is particularly problematic for me, as I need a properly 
> functioning "delay" value for my application.
> 
> This is using alsa from 2.6test5 kernel.

is it through the rate plugin?
there was a bug about rate plugin together with dmix, which was fixed
recently on cvs.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Wed, 17 Sep 2003 19:33:29 +0100,
> James Courtier-Dutton wrote:
> 
>>Output from sending stereo sound to the "dmix" device.
>>bash-2.05b# cat status
>>state: RUNNING
>>trigger_time: 1063822024.640173000
>>tstamp      : 1063822060.456968000
>>delay       : -1719463
>>avail       : 1731463
>>avail_max   : 1731463
>>-----
>>hw_ptr      : 1719463
>>appl_ptr    : 0
>>bash-2.05b#
>>
>>Output from sending stereo sound to the "front" device.
>>bash-2.05b# cat status
>>state: RUNNING
>>trigger_time: 1063823309.038609000
>>tstamp      : 1063823320.869677000
>>delay       : 14161
>>avail       : 2223
>>avail_max   : 3586
>>-----
>>hw_ptr      : 567983
>>appl_ptr    : 582144
>>
>>As you can see, the "front" device acts correctly, with all the pointers 
>>acting as they should.
>>But with "dmix", all the pointers are wrong.
>>This is particularly problematic for me, as I need a properly 
>>functioning "delay" value for my application.
>>
>>This is using alsa from 2.6test5 kernel.
> 
> 
> is it through the rate plugin?
> there was a bug about rate plugin together with dmix, which was fixed
> recently on cvs.
> 
> 
> Takashi
> 
> 
How do I tell if it is using the "rate" plugin?
I am outputing a single stereo signal at 48khz, 16 bits.
Where do I configure the rate that dmix works at natively?

Cheers
James




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[Takashi Iwai]

At Wed, 17 Sep 2003 20:01:36 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> > At Wed, 17 Sep 2003 19:33:29 +0100,
> > James Courtier-Dutton wrote:
> > 
> >>Output from sending stereo sound to the "dmix" device.
> >>bash-2.05b# cat status
> >>state: RUNNING
> >>trigger_time: 1063822024.640173000
> >>tstamp      : 1063822060.456968000
> >>delay       : -1719463
> >>avail       : 1731463
> >>avail_max   : 1731463
> >>-----
> >>hw_ptr      : 1719463
> >>appl_ptr    : 0
> >>bash-2.05b#
> >>
> >>Output from sending stereo sound to the "front" device.
> >>bash-2.05b# cat status
> >>state: RUNNING
> >>trigger_time: 1063823309.038609000
> >>tstamp      : 1063823320.869677000
> >>delay       : 14161
> >>avail       : 2223
> >>avail_max   : 3586
> >>-----
> >>hw_ptr      : 567983
> >>appl_ptr    : 582144
> >>
> >>As you can see, the "front" device acts correctly, with all the pointers 
> >>acting as they should.
> >>But with "dmix", all the pointers are wrong.
> >>This is particularly problematic for me, as I need a properly 
> >>functioning "delay" value for my application.
> >>
> >>This is using alsa from 2.6test5 kernel.
> > 
> > 
> > is it through the rate plugin?
> > there was a bug about rate plugin together with dmix, which was fixed
> > recently on cvs.
> > 
> > 
> > Takashi
> > 
> > 
> How do I tell if it is using the "rate" plugin?
> I am outputing a single stereo signal at 48khz, 16 bits.
> Where do I configure the rate that dmix works at natively?

at best you can dump the pcm status to the error log from your app.
to check the rate conversion, comparing the status in
/proc/asound/card0/pcm0p/sub0/hw_params would be enough, though.
if the hardware uses a different sample rate, surely the rate plugin
is working.

anyway, if you're using the cvs version of yesterday/today, it must be
ok.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Wed, 17 Sep 2003 20:01:36 +0100,
> James Courtier-Dutton wrote:
> 
>>Takashi Iwai wrote:
>>
>>>At Wed, 17 Sep 2003 19:33:29 +0100,
>>>James Courtier-Dutton wrote:
>>>
>>>
>>>>Output from sending stereo sound to the "dmix" device.
>>>>bash-2.05b# cat status
>>>>state: RUNNING
>>>>trigger_time: 1063822024.640173000
>>>>tstamp      : 1063822060.456968000
>>>>delay       : -1719463
>>>>avail       : 1731463
>>>>avail_max   : 1731463
>>>>-----
>>>>hw_ptr      : 1719463
>>>>appl_ptr    : 0
>>>>bash-2.05b#
>>>>
>>>>Output from sending stereo sound to the "front" device.
>>>>bash-2.05b# cat status
>>>>state: RUNNING
>>>>trigger_time: 1063823309.038609000
>>>>tstamp      : 1063823320.869677000
>>>>delay       : 14161
>>>>avail       : 2223
>>>>avail_max   : 3586
>>>>-----
>>>>hw_ptr      : 567983
>>>>appl_ptr    : 582144
>>>>
>>>>As you can see, the "front" device acts correctly, with all the pointers 
>>>>acting as they should.
>>>>But with "dmix", all the pointers are wrong.
>>>>This is particularly problematic for me, as I need a properly 
>>>>functioning "delay" value for my application.
>>>>
>>>>This is using alsa from 2.6test5 kernel.
>>>
>>>
>>>is it through the rate plugin?
>>>there was a bug about rate plugin together with dmix, which was fixed
>>>recently on cvs.
>>>
>>>
>>>Takashi
>>>
>>>
>>
>>How do I tell if it is using the "rate" plugin?
>>I am outputing a single stereo signal at 48khz, 16 bits.
>>Where do I configure the rate that dmix works at natively?
> 
> 
> at best you can dump the pcm status to the error log from your app.
> to check the rate conversion, comparing the status in
> /proc/asound/card0/pcm0p/sub0/hw_params would be enough, though.
> if the hardware uses a different sample rate, surely the rate plugin
> is working.
> 
> anyway, if you're using the cvs version of yesterday/today, it must be
> ok.
> 
> 
> Takashi
> 
> 
"rate" is not being used.
application outputting at 48khz, hw_params set at 48khz.
I have tested with latest alsa-lib anon cvs.

So, this is a new bug.

Cheers
James



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[Takashi Iwai]

At Wed, 17 Sep 2003 21:46:52 +0100,
James Courtier-Dutton wrote:
> 
> Takashi Iwai wrote:
> > At Wed, 17 Sep 2003 20:01:36 +0100,
> > James Courtier-Dutton wrote:
> > 
> >>Takashi Iwai wrote:
> >>
> >>>At Wed, 17 Sep 2003 19:33:29 +0100,
> >>>James Courtier-Dutton wrote:
> >>>
> >>>
> >>>>Output from sending stereo sound to the "dmix" device.
> >>>>bash-2.05b# cat status
> >>>>state: RUNNING
> >>>>trigger_time: 1063822024.640173000
> >>>>tstamp      : 1063822060.456968000
> >>>>delay       : -1719463
> >>>>avail       : 1731463
> >>>>avail_max   : 1731463
> >>>>-----
> >>>>hw_ptr      : 1719463
> >>>>appl_ptr    : 0
> >>>>bash-2.05b#
> >>>>
> >>>>Output from sending stereo sound to the "front" device.
> >>>>bash-2.05b# cat status
> >>>>state: RUNNING
> >>>>trigger_time: 1063823309.038609000
> >>>>tstamp      : 1063823320.869677000
> >>>>delay       : 14161
> >>>>avail       : 2223
> >>>>avail_max   : 3586
> >>>>-----
> >>>>hw_ptr      : 567983
> >>>>appl_ptr    : 582144
> >>>>
> >>>>As you can see, the "front" device acts correctly, with all the pointers 
> >>>>acting as they should.
> >>>>But with "dmix", all the pointers are wrong.
> >>>>This is particularly problematic for me, as I need a properly 
> >>>>functioning "delay" value for my application.
> >>>>
> >>>>This is using alsa from 2.6test5 kernel.
> >>>
> >>>
> >>>is it through the rate plugin?
> >>>there was a bug about rate plugin together with dmix, which was fixed
> >>>recently on cvs.
> >>>
> >>>
> >>>Takashi
> >>>
> >>>
> >>
> >>How do I tell if it is using the "rate" plugin?
> >>I am outputing a single stereo signal at 48khz, 16 bits.
> >>Where do I configure the rate that dmix works at natively?
> > 
> > 
> > at best you can dump the pcm status to the error log from your app.
> > to check the rate conversion, comparing the status in
> > /proc/asound/card0/pcm0p/sub0/hw_params would be enough, though.
> > if the hardware uses a different sample rate, surely the rate plugin
> > is working.
> > 
> > anyway, if you're using the cvs version of yesterday/today, it must be
> > ok.
> > 
> > 
> > Takashi
> > 
> > 
> "rate" is not being used.
> application outputting at 48khz, hw_params set at 48khz.
> I have tested with latest alsa-lib anon cvs.
> 
> So, this is a new bug.

looks like so.

i guess it's stopping at the same position as well as the rate plugin
bug hit.  it was at snd_pcm_wait() in snd_pcm_write_areas().  but it
should be better to check it via gdb.

as you see, delay shows a minus value, that is the underrun.
and the appl_ptr is zero.  this is the hint to debug.

but, i have no time in this week to debug further...


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[AthlonRob]

On Wed, 2003-09-17 at 11:52, Takashi Iwai wrote:

> is it through the rate plugin?
> there was a bug about rate plugin together with dmix, which was fixed
> recently on cvs.

Is the 'rate' plugin == the 'plug' plugin?

Or, does this bug which was just fixed happen when using 'plug' as well
as 'rate' ?

If so, it may explain why dmix isn't working for me.  :-)

Rob

(re-sent as I sent it from the wrong address last night)



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[Clemens Ladisch]

AthlonRob wrote:
> On Wed, 2003-09-17 at 11:52, Takashi Iwai wrote:
>
> > is it through the rate plugin?
> > there was a bug about rate plugin together with dmix, which was fixed
> > recently on cvs.
>
> Is the 'rate' plugin == the 'plug' plugin?

No. Yes.  ;-)  Well, the "plug" plugin uses the same code as the
"rate" plugin when converting the sample rate.


HTH
Clemens




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[Jaroslav Kysela]

On Sat, 20 Sep 2003, Clemens Ladisch wrote:

> AthlonRob wrote:
> > On Wed, 2003-09-17 at 11:52, Takashi Iwai wrote:
> >
> > > is it through the rate plugin?
> > > there was a bug about rate plugin together with dmix, which was fixed
> > > recently on cvs.
> >
> > Is the 'rate' plugin == the 'plug' plugin?
>
> No. Yes.  ;-)  Well, the "plug" plugin uses the same code as the
> "rate" plugin when converting the sample rate.

More precisely, the plug plugin uses other (more elementary) plugins for
the automatic stream conversion, but you can use the rate plugin
separately as well.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[AthlonRob]

On Sat, 2003-09-20 at 04:07, Clemens Ladisch wrote:
> AthlonRob wrote:
> > On Wed, 2003-09-17 at 11:52, Takashi Iwai wrote:
> >
> > > is it through the rate plugin?
> > > there was a bug about rate plugin together with dmix, which was fixed
> > > recently on cvs.
> >
> > Is the 'rate' plugin == the 'plug' plugin?
> 
> No. Yes.  ;-)  Well, the "plug" plugin uses the same code as the
> "rate" plugin when converting the sample rate.

I guess what I'm actually asking is....

I was unable to get the plug plugin working with the dmix plugin. 
Seperately, they both worked (although the dmix only with very few WAV
files).... but together, they didn't work at all.  They acted like the
PCM was busy all the time, whenever audio was to be sent to them.

Is this dmix/rate bug they recently fixed... going to fix my problem
above, or is it an unrelated bug?

-- 
Rob                                |  If not safe,
   Jabber: athlonrob at axpr.net   |    one can never be free.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[AthlonRob]

On Sun, 2003-09-21 at 10:06, AthlonRob wrote:

> I was unable to get the plug plugin working with the dmix plugin. 
> Seperately, they both worked (although the dmix only with very few WAV
> files).... but together, they didn't work at all.  They acted like the
> PCM was busy all the time, whenever audio was to be sent to them.
> 
> Is this dmix/rate bug they recently fixed... going to fix my problem
> above, or is it an unrelated bug?

I just upgraded to 0.9.7, which I would assume includes whatever patch
was provided to CVS to let dmix and rate play nicely together...

I wanted to report, I'm now able to use plug and dmix together, quite
nicely.  :-)

It gets a little shakey with a few streams running, but it's more than I
was expecting - sound events are now able to play while I listen to
stuff.  :-)

Thanks!

-- 
Rob                                |  If not safe,
   Jabber: athlonrob at axpr.net   |    one can never be free.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[Jaroslav Kysela]

On Wed, 17 Sep 2003, James Courtier-Dutton wrote:

> Output from sending stereo sound to the "dmix" device.
> bash-2.05b# cat status
> state: RUNNING
> trigger_time: 1063822024.640173000
> tstamp      : 1063822060.456968000
> delay       : -1719463
> avail       : 1731463
> avail_max   : 1731463
> -----
> hw_ptr      : 1719463
> appl_ptr    : 0
> bash-2.05b#
>
> Output from sending stereo sound to the "front" device.
> bash-2.05b# cat status
> state: RUNNING
> trigger_time: 1063823309.038609000
> tstamp      : 1063823320.869677000
> delay       : 14161
> avail       : 2223
> avail_max   : 3586
> -----
> hw_ptr      : 567983
> appl_ptr    : 582144
>
> As you can see, the "front" device acts correctly, with all the pointers
> acting as they should.
> But with "dmix", all the pointers are wrong.
> This is particularly problematic for me, as I need a properly
> functioning "delay" value for my application.
>
> This is using alsa from 2.6test5 kernel.

This is absolutely ok. The device is running in no-xrun mode, because
multi-applications have access to it. The dmix plugin has own hw_ptr and
appl_ptr for each instance and mangles the information from kernel to
correct values to follow the ALSA API.

What is your problem? The resolution of the dmix plugin is always one
period (to make things faster), but it's not a problem to add the slow
calls.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> On Wed, 17 Sep 2003, James Courtier-Dutton wrote:
> 
> 
>>Output from sending stereo sound to the "dmix" device.
>>bash-2.05b# cat status
>>state: RUNNING
>>trigger_time: 1063822024.640173000
>>tstamp      : 1063822060.456968000
>>delay       : -1719463
>>avail       : 1731463
>>avail_max   : 1731463
>>-----
>>hw_ptr      : 1719463
>>appl_ptr    : 0
>>bash-2.05b#
>>
>>Output from sending stereo sound to the "front" device.
>>bash-2.05b# cat status
>>state: RUNNING
>>trigger_time: 1063823309.038609000
>>tstamp      : 1063823320.869677000
>>delay       : 14161
>>avail       : 2223
>>avail_max   : 3586
>>-----
>>hw_ptr      : 567983
>>appl_ptr    : 582144
>>
>>As you can see, the "front" device acts correctly, with all the pointers
>>acting as they should.
>>But with "dmix", all the pointers are wrong.
>>This is particularly problematic for me, as I need a properly
>>functioning "delay" value for my application.
>>
>>This is using alsa from 2.6test5 kernel.
> 
> 
> This is absolutely ok. The device is running in no-xrun mode, because
> multi-applications have access to it. The dmix plugin has own hw_ptr and
> appl_ptr for each instance and mangles the information from kernel to
> correct values to follow the ALSA API.
> 
> What is your problem? The resolution of the dmix plugin is always one
> period (to make things faster), but it's not a problem to add the slow
> calls.
> 
> 						Jaroslav
> 
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SuSE Labs
> 
> 

The problem is that my application relies on a correct "delay" value, so 
that it can use it to keep sound/video in sync.

An example of more status output while playing a .wav file with aplay -D 
dmix. Each "cat status" is typed in quickly after each other.

bash-2.05b# cat status
state: RUNNING
trigger_time: 1063888806.325296000
tstamp      : 1063888809.954270000
delay       : -174225
avail       : 186225
avail_max   : 186225
-----
hw_ptr      : 174225
appl_ptr    : 0
bash-2.05b# cat status
state: RUNNING
trigger_time: 1063888806.325296000
tstamp      : 1063888810.491712000
delay       : -200026
avail       : 212026
avail_max   : 212026
-----
hw_ptr      : 200026
appl_ptr    : 0
bash-2.05b# cat status
state: RUNNING
trigger_time: 1063888806.325296000
tstamp      : 1063888811.036897000
delay       : -226198
avail       : 238198
avail_max   : 238198
-----
hw_ptr      : 226198
appl_ptr    : 0

As you can see, the sound is being played, and comes out of the 
speakers, and there are no xruns, because if there were I would hear them.
For the "dmix" device.
As the buffer size is 12000, avail/avail_max should never reach a value 
 > buffer_size.
delay should never reach a size > buffer_size (12000).

My guess is that delay = appl_ptr - hw_ptr, and thus the reason for it 
being negative.

Cheers
James



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[Jaroslav Kysela]

On Thu, 18 Sep 2003, James Courtier-Dutton wrote:

> Jaroslav Kysela wrote:
> > On Wed, 17 Sep 2003, James Courtier-Dutton wrote:
> >
> >
> >>Output from sending stereo sound to the "dmix" device.
> >>bash-2.05b# cat status
> >>state: RUNNING
> >>trigger_time: 1063822024.640173000
> >>tstamp      : 1063822060.456968000
> >>delay       : -1719463
> >>avail       : 1731463
> >>avail_max   : 1731463
> >>-----
> >>hw_ptr      : 1719463
> >>appl_ptr    : 0
> >>bash-2.05b#
> >>
> >>Output from sending stereo sound to the "front" device.
> >>bash-2.05b# cat status
> >>state: RUNNING
> >>trigger_time: 1063823309.038609000
> >>tstamp      : 1063823320.869677000
> >>delay       : 14161
> >>avail       : 2223
> >>avail_max   : 3586
> >>-----
> >>hw_ptr      : 567983
> >>appl_ptr    : 582144
> >>
> >>As you can see, the "front" device acts correctly, with all the pointers
> >>acting as they should.
> >>But with "dmix", all the pointers are wrong.
> >>This is particularly problematic for me, as I need a properly
> >>functioning "delay" value for my application.
> >>
> >>This is using alsa from 2.6test5 kernel.
> >
> >
> > This is absolutely ok. The device is running in no-xrun mode, because
> > multi-applications have access to it. The dmix plugin has own hw_ptr and
> > appl_ptr for each instance and mangles the information from kernel to
> > correct values to follow the ALSA API.
> >
> > What is your problem? The resolution of the dmix plugin is always one
> > period (to make things faster), but it's not a problem to add the slow
> > calls.
> >
> > 						Jaroslav
> >
> > -----
> > Jaroslav Kysela <perex@suse.cz>
> > Linux Kernel Sound Maintainer
> > ALSA Project, SuSE Labs
> >
> >
>
> The problem is that my application relies on a correct "delay" value, so
> that it can use it to keep sound/video in sync.

I'm asking again, what is your problem in your application? Yes, avail in
driver is negative, because appl_ptr is NOT updated from the dmix clients
(and it is not possible - it is a shared thing), but the dmix plugin
should pass the right value (non-negative) to application. Please, don't
look to /proc tree with the dmix plugin. Appearently, you're confused,
because the dmix uses some tricks to let things working.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[James Courtier-Dutton]

Jaroslav Kysela wrote:
> 
> 
> I'm asking again, what is your problem in your application? Yes, avail in
> driver is negative, because appl_ptr is NOT updated from the dmix clients
> (and it is not possible - it is a shared thing), but the dmix plugin
> should pass the right value (non-negative) to application. Please, don't
> look to /proc tree with the dmix plugin. Appearently, you're confused,
> because the dmix uses some tricks to let things working.
> 
> 						Jaroslav
> 
> -----
> Jaroslav Kysela <perex@suse.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, SuSE Labs
> 
> 

You are correct, my application does in fact get correct "delay" values, 
but the /proc/asound/card0/pcm0p/sub0/status does not show these when 
using dmix.

The sound output from my application is very broken up when using 
"dmix", but sounds fine when using "front".

The break up sounds like one period sound, one period mute, one period 
sound, one period mute.

It must be something in my application, because aplay does not break up.

I suspect it is my application trying to do xrun recovery or something 
like that, but dmix runs freewheel even on xruns, so I might have to 
change some of my code. My reasoning behind this, is that with "front", 
I can do xrun recovery by stopping and then restarting the pcm, so the 
recovery is very quick, but with dmix, I have to wait a whole period 
before sound output starts again.

Cheers
James



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[Jaroslav Kysela]

On Thu, 18 Sep 2003, James Courtier-Dutton wrote:

> You are correct, my application does in fact get correct "delay" values,
> but the /proc/asound/card0/pcm0p/sub0/status does not show these when
> using dmix.
>
> The sound output from my application is very broken up when using
> "dmix", but sounds fine when using "front".
>
> The break up sounds like one period sound, one period mute, one period
> sound, one period mute.
>
> It must be something in my application, because aplay does not break up.
>
> I suspect it is my application trying to do xrun recovery or something
> like that, but dmix runs freewheel even on xruns, so I might have to
> change some of my code. My reasoning behind this, is that with "front",
> I can do xrun recovery by stopping and then restarting the pcm, so the
> recovery is very quick, but with dmix, I have to wait a whole period
> before sound output starts again.

A quick idea: Do you use snd_pcm_poll_descriptors_revents() function to
parse returned poll events? The dmix plugin uses the PCM timer as the poll
source, but it does not use POLLOUT but POLLIN !!!

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[Paul Davis]

>The problem is that my application relies on a correct "delay" value, so 
>that it can use it to keep sound/video in sync.

although i think that the dmix plugin should work correctly, i would
be suprised, no, lets just say pleasantly suprised, if you could get
perfect sound/video sync using it. otoh, i don't recall enough of
jaroslav's description of how it worked at ZKM to really judge that.

i suspect its a bit like trying to an audio interface with a "sloppy"
hardware pointer. jaroslav will correct me, right jaroslav?

--p


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: status pointer's problem with dmix.

[Jaroslav Kysela]

On Thu, 18 Sep 2003, Paul Davis wrote:

> >The problem is that my application relies on a correct "delay" value, so
> >that it can use it to keep sound/video in sync.
>
> although i think that the dmix plugin should work correctly, i would
> be suprised, no, lets just say pleasantly suprised, if you could get
> perfect sound/video sync using it. otoh, i don't recall enough of
> jaroslav's description of how it worked at ZKM to really judge that.
>
> i suspect its a bit like trying to an audio interface with a "sloppy"
> hardware pointer. jaroslav will correct me, right jaroslav?

Actually the dmix plugin offers the stream position in "period-size"
steps, but it's no problem to call the standard ioctl() from the dmix
plugin to the real device to obtain the accurate stream position. I think
that it's the problem which James is noting.

						Jaroslav

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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf