dmix, pause, and snd_pcm_delay

dmix, pause, and snd_pcm_delay

[Ryan Gammon]

Hi guys,

I've been fooling around with the helix client media playback engine 
from helixcommunity.org in combination with alsa-lib-1.0.4, with the 
goal of getting audio playing back properly.

My set-up looks something like this:

===============
| Esound apps |
===============
      ||
      ||
=================      ===================
| Esound hacked |      | Helix Client w/ |
| to work with  |      | ALSA support    |
| dmix          |      ===================
=================             /
       \                    /
         \                /
         =======================
         | dmix server running |
         | in an esound forked |
         | process             |
         =======================
                   ||
                   ||
           =================
           | snd_usb_audio |
           =================


Esound apps here are mostly apps with an alsa implementation that's not 
up to supporting dmix. This has the additional benefit of hosting the 
alsa dmix server in a esound process, which is good, as dmix doesn't 
seem to run properly if it's in a process forked from the helix client. 
This might have something to do with the various threads created by the 
client before opening the audio device, and the fact that the dmix 
server doesn't exec after the fork, but I haven't really looked too 
deeply into it.

My main difficulty is in implementing the 
CAudioOutUNIX::_GetBytesActualyPlayed (sic) function in the helix code 
base. The goal of this function is to return the number of bytes that 
have been played by the sound device. It is mostly used for ensuring 
video and audio are synchronized.

I've tried to implement this in a couple of different ways:
1. Using mmaped timestamps, and converting the time interval between now 
and when playback triggered into bytes.
2. Using bytes_written - snd_pcm_delay()
3. Using bytes_written - (initial snd_pcm_avail_update() value - current 
snd_pcm_avail_update() value
4. Using the snd_timer api (still figuring this out)
5. Something with snd_pcm_sync_id_t (not sure what this is, or how to 
use it)

I've run into various problems with all these methods.

1. I find that, while I get a valid timestamp from 
snd_pcm_status_get_trigger_tstamp, snd_pcm_status_get_tstamp 
consistantly gives me a timestamp of 0 s + 0 us.

2. This works well until I try to pause. dmix claims support for 
hardware pause, but when I pause, the hw.ptr seems to keep marching on, 
and when I unpause, snd_pcm_delay() returns a negative value, as the 
hardware pointer has become greater than the software pointer.

3. Similar problem to (2) -- hw.ptr seems to get out of sync.

4. Not sure how to get playback and the timer to start at the same time. 
Maybe I have to set the start threshold on the pcm device such that I 
start playback manually, and start the timer at the same time as 
playback? I'm also worried that there might be drift between the timer 
and the PCM device when the timer isn't something that's on the sound 
card. Dealing with overruns and underruns also seems like it would be 
complicated here.

5. Not sure what snd_pcm_sync_id_t is nor how one would use it.

Anyone have any tips or tricks? I'm willing to some poking around 
alsa-lib if what I'm looking at here appears to be a dmix issue.

Thanks,

Ryan


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

[patch] Re: dmix, pause, and snd_pcm_delay

[Ryan Gammon]

Disabling hardware pause in dmix seems to solve my problems:

--- pcm_plug.c~ 2004-02-08 02:20:03.000000000 -0800
+++ pcm_plug.c  2004-07-06 22:58:24.000000000 -0700
@@ -848,7 +848,7 @@
        if (err < 0)
                return err;
        /* FIXME */
-       params->info &= ~(SND_PCM_INFO_MMAP | SND_PCM_INFO_MMAP_VALID);
+       params->info &= ~(SND_PCM_INFO_MMAP | SND_PCM_INFO_MMAP_VALID | 
SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME);
        return 0;
 }

Is this a reasonable fix?


Ryan Gammon wrote:

> Hi guys,
>
> I've been fooling around with the helix client media playback engine 
> from helixcommunity.org in combination with alsa-lib-1.0.4, with the 
> goal of getting audio playing back properly.
>
> My set-up looks something like this:
>
> ===============
> | Esound apps |
> ===============
>      ||
>      ||
> =================      ===================
> | Esound hacked |      | Helix Client w/ |
> | to work with  |      | ALSA support    |
> | dmix          |      ===================
> =================             /
>       \                    /
>         \                /
>         =======================
>         | dmix server running |
>         | in an esound forked |
>         | process             |
>         =======================
>                   ||
>                   ||
>           =================
>           | snd_usb_audio |
>           =================
>
>
> Esound apps here are mostly apps with an alsa implementation that's 
> not up to supporting dmix. This has the additional benefit of hosting 
> the alsa dmix server in a esound process, which is good, as dmix 
> doesn't seem to run properly if it's in a process forked from the 
> helix client. This might have something to do with the various threads 
> created by the client before opening the audio device, and the fact 
> that the dmix server doesn't exec after the fork, but I haven't really 
> looked too deeply into it.
>
> My main difficulty is in implementing the 
> CAudioOutUNIX::_GetBytesActualyPlayed (sic) function in the helix code 
> base. The goal of this function is to return the number of bytes that 
> have been played by the sound device. It is mostly used for ensuring 
> video and audio are synchronized.
>
> I've tried to implement this in a couple of different ways:
> 1. Using mmaped timestamps, and converting the time interval between 
> now and when playback triggered into bytes.
> 2. Using bytes_written - snd_pcm_delay()
> 3. Using bytes_written - (initial snd_pcm_avail_update() value - 
> current snd_pcm_avail_update() value
> 4. Using the snd_timer api (still figuring this out)
> 5. Something with snd_pcm_sync_id_t (not sure what this is, or how to 
> use it)
>
> I've run into various problems with all these methods.
>
> 1. I find that, while I get a valid timestamp from 
> snd_pcm_status_get_trigger_tstamp, snd_pcm_status_get_tstamp 
> consistantly gives me a timestamp of 0 s + 0 us.
>
> 2. This works well until I try to pause. dmix claims support for 
> hardware pause, but when I pause, the hw.ptr seems to keep marching 
> on, and when I unpause, snd_pcm_delay() returns a negative value, as 
> the hardware pointer has become greater than the software pointer.
>
> 3. Similar problem to (2) -- hw.ptr seems to get out of sync.
>
> 4. Not sure how to get playback and the timer to start at the same 
> time. Maybe I have to set the start threshold on the pcm device such 
> that I start playback manually, and start the timer at the same time 
> as playback? I'm also worried that there might be drift between the 
> timer and the PCM device when the timer isn't something that's on the 
> sound card. Dealing with overruns and underruns also seems like it 
> would be complicated here.
>
> 5. Not sure what snd_pcm_sync_id_t is nor how one would use it.
>
> Anyone have any tips or tricks? I'm willing to some poking around 
> alsa-lib if what I'm looking at here appears to be a dmix issue.
>
> Thanks,
>
> Ryan
>



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: dmix, pause, and snd_pcm_delay

[Takashi Iwai]

At Tue, 06 Jul 2004 00:46:50 -0700,
Ryan Gammon wrote:
> 
> I've tried to implement this in a couple of different ways:
> 1. Using mmaped timestamps, and converting the time interval between now 
> and when playback triggered into bytes.
> 2. Using bytes_written - snd_pcm_delay()
> 3. Using bytes_written - (initial snd_pcm_avail_update() value - current 
> snd_pcm_avail_update() value
> 4. Using the snd_timer api (still figuring this out)
> 5. Something with snd_pcm_sync_id_t (not sure what this is, or how to 
> use it)

(2) should be the proper way to work.

> 2. This works well until I try to pause. dmix claims support for 
> hardware pause, but when I pause, the hw.ptr seems to keep marching on, 
> and when I unpause, snd_pcm_delay() returns a negative value, as the 
> hardware pointer has become greater than the software pointer.

Ok, it's a bug.
A workaround is to disable pause/resume as your patch.
I'll apply it cvs.

A better fix would be the proper implementation, though...


Takashi


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: dmix, pause, and snd_pcm_delay

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

At Tue, 13 Jul 2004 11:39:35 +0200,
I wrote:
> 
> > 2. This works well until I try to pause. dmix claims support for 
> > hardware pause, but when I pause, the hw.ptr seems to keep marching on, 
> > and when I unpause, snd_pcm_delay() returns a negative value, as the 
> > hardware pointer has become greater than the software pointer.
> 
> Ok, it's a bug.
> A workaround is to disable pause/resume as your patch.
> I'll apply it cvs.

After rethought, it doesn't seem to be a good idea to disable them in
pcm_plug.c.  Does the attached patch work alternatively?


Takashi

[-- Attachment #2: Type: text/plain, Size: 677 bytes --]

Index: alsa-lib/src/pcm/pcm_direct.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/src/pcm/pcm_direct.c,v
retrieving revision 1.15
diff -u -r1.15 pcm_direct.c
--- alsa-lib/src/pcm/pcm_direct.c	7 Apr 2004 10:02:39 -0000	1.15
+++ alsa-lib/src/pcm/pcm_direct.c	13 Jul 2004 09:49:14 -0000
@@ -807,7 +807,7 @@
 	dmix->shmptr->s.rate = spcm->rate;
 	dmix->shmptr->s.format = spcm->format;
 	dmix->shmptr->s.boundary = spcm->boundary;
-	dmix->shmptr->s.info = spcm->info;
+	dmix->shmptr->s.info = spcm->info & ~(SND_PCM_INFO_PAUSE|SND_PCM_INFO_RESUME);
 	dmix->shmptr->s.msbits = spcm->msbits;
 
 	spcm->donot_close = 1;