ring buffer pointer accuracy.

ring buffer pointer accuracy.

[James Courtier-Dutton]

Hi,

When an application reads the "avail" or "delay" pcm values: -
1) how accurate are they?
2) does the accuracy depend on the sound card driver being used.

The reason I ask this, is that I am going to be writing an alsa driver 
for bluetooth headsets.
With bluetooth headsets, sound is sent to the bluetooth headset inside a 
packet.
This packet is 27 bytes long, and contains 24 audio samples (8 bit mono, 
8000hz) and 3 bytes header.
This would mean that the "avail" and "delay" pointers will only be 
updated once every 24 samples, and will always go in 24 sample increments.
This means that the "avail" and "delay" pointers are only accurate to 
the nearest 3 ms.

Do any other alsa drivers suffer from this, or are they all sample 
accurate and updated as each sample is sent to the speakers.

It would be nice for the application to be able to determine how 
accurate the "avail" and "delay" pointers are.
If an application is trying to syncronise video to audio, it will need 
to know how accurate the snd_pcm_delay() pointer is.
I.E. Is snd_pcm_delay() updated as each sample is output to the 
speakers, or is it only updated as each block of 24 samples are output.
As you can see, if the application trys to syncronise to sample 
accuracy, it will fail badly with bluetooth headsets, but if the 
application can be told by alsa that it should only try to syncronise if 
it is more that 24 samples out of sync, the problem will be solved.

Cheers
James



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps

Re: ring buffer pointer accuracy.

[Giuliano Pochini]

On Thu, 10 Jul 2003 16:31:28 +0100
James Courtier-Dutton <James@superbug.demon.co.uk> wrote:

> Hi,
>
> When an application reads the "avail" or "delay" pcm values: -
> 1) how accurate are they?
> 2) does the accuracy depend on the sound card driver being used.

Worst case accuracy is about one period AFAIK. It depends on the sound chip
because the low level driver reads the DMA pointer (or something) from some
hardware register or it can know the DMA pointer when it receives an interrupt
at the end of a period.

> This means that the "avail" and "delay" pointers are only accurate to 
> the nearest 3 ms.
> Do any other alsa drivers suffer from this, or are they all sample 
> accurate and updated as each sample is sent to the speakers.

No, for example the DMA pointer of Echoaudio cards has a precision of 32
frames. But from userspace it can be a lot worse than that. You have to
take into account process scheduling, disk i/o, network i/o...

Bye.


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: ring buffer pointer accuracy.

[Takashi Iwai]

At Fri, 11 Jul 2003 17:28:08 +0200,
Giuliano Pochini wrote:
> 
> On Thu, 10 Jul 2003 16:31:28 +0100
> James Courtier-Dutton <James@superbug.demon.co.uk> wrote:
> 
> > Hi,
> >
> > When an application reads the "avail" or "delay" pcm values: -
> > 1) how accurate are they?
> > 2) does the accuracy depend on the sound card driver being used.
> 
> Worst case accuracy is about one period AFAIK. It depends on the sound chip
> because the low level driver reads the DMA pointer (or something) from some
> hardware register or it can know the DMA pointer when it receives an interrupt
> at the end of a period.

yes.  if the accuracy is in period size, at least it should work
somehow.  e.g. the time-slider of a player might not move so smooth
but it must not be critical.


Takashi


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: ring buffer pointer accuracy.

[James Courtier-Dutton]

Takashi Iwai wrote:
> At Fri, 11 Jul 2003 17:28:08 +0200,
> Giuliano Pochini wrote:
> 
>>On Thu, 10 Jul 2003 16:31:28 +0100
>>James Courtier-Dutton <James@superbug.demon.co.uk> wrote:
>>
>>
>>>Hi,
>>>
>>>When an application reads the "avail" or "delay" pcm values: -
>>>1) how accurate are they?
>>>2) does the accuracy depend on the sound card driver being used.
>>
>>Worst case accuracy is about one period AFAIK. It depends on the sound chip
>>because the low level driver reads the DMA pointer (or something) from some
>>hardware register or it can know the DMA pointer when it receives an interrupt
>>at the end of a period.
> 
> 
> yes.  if the accuracy is in period size, at least it should work
> somehow.  e.g. the time-slider of a player might not move so smooth
> but it must not be critical.
> 
> 
> Takashi
> 
> 
I would like some idea of how accurate the snd_pcm_delay() result is 
likely to be. If I am trying to syncronise video to audio, and I notice 
a difference between audio and video, I need to know how accurate I can 
make it.
If some cards only update "delay" once per period, but others update it 
all the time, I would like the application to know about it, so it can 
decide how accurately it can actually get audio and video in sync.
I.e. On some cards it would only correct for sync if it is off by 1 
period or more, but with other audio cards it could be sample accurate.
I have a sb live audio card and it seems to update with sample accuracy.

Cheers
James




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: ring buffer pointer accuracy.

[Giuliano Pochini]

On 14-Jul-2003 James Courtier-Dutton wrote:
>>>Worst case accuracy is about one period AFAIK. It depends on the sound chip
>>>because the low level driver reads the DMA pointer (or something) from some
>>>hardware register or it can know the DMA pointer when it receives an interrupt
>>>at the end of a period.
>>
>>
>> yes.  if the accuracy is in period size, at least it should work
>> somehow.  e.g. the time-slider of a player might not move so smooth
>> but it must not be critical.
>>
>>
> I would like some idea of how accurate the snd_pcm_delay() result is
> likely to be. If I am trying to syncronise video to audio, and I notice
> a difference between audio and video, I need to know how accurate I can
> make it.

I suppose you need a precision of 42ms (the duration of a cinema frame).
You can read the position at intervals <= 42ms. If the value you read is
different then the previous one, you know that value is up to date.
You know exactly when you started to play the sound. If you do your own
timing and you take into account the period time, you only need to read
position 3-4 times every 10s or so to check if you are losing sync.
Even if you have a really bad soundcard, it's unlikely the sample clock
skews more than 1%.

> If some cards only update "delay" once per period, but others update it
> all the time, I would like the application to know about it, so it can
> decide how accurately it can actually get audio and video in sync.

You can use shorter periods if your cards allows it.


Bye.



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: ring buffer pointer accuracy.

[Måns Rullgård]

Giuliano Pochini <pochini@shiny.it> writes:

>> I would like some idea of how accurate the snd_pcm_delay() result is
>> likely to be. If I am trying to syncronise video to audio, and I notice
>> a difference between audio and video, I need to know how accurate I can
>> make it.
>
> I suppose you need a precision of 42ms (the duration of a cinema frame).
> You can read the position at intervals <= 42ms. If the value you read is
> different then the previous one, you know that value is up to date.
> You know exactly when you started to play the sound. If you do your own
> timing and you take into account the period time, you only need to read
> position 3-4 times every 10s or so to check if you are losing sync.

You could use the ALSA timer interface.  It gives a resolution equal
to the period time.  If that's too long time, you can use the system
clock to interpolate.

> Even if you have a really bad soundcard, it's unlikely the sample clock
> skews more than 1%.

1% would be about a minute at the end of normal movie.  That's not
what I like to call acceptable.

>> If some cards only update "delay" once per period, but others update it
>> all the time, I would like the application to know about it, so it can
>> decide how accurately it can actually get audio and video in sync.
>
> You can use shorter periods if your cards allows it.

Most cards I've come across support period lengths of down to 10 ms or
less.  That's plenty enough for video playback.

-- 
Måns Rullgård
mru@users.sf.net



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1