Available frames > buffer size

Available frames > buffer size

[Rob Duncan]

Is it ever correct for snd_pcm_avail() to return a value that’s greater than that returned by snd_pcm_hw_params_get_buffer_size()?

I’m trying to track down some unexpected underruns in my application and I notice that when they occur I also see that the available frames count is wrong.

For example here are a couple of lines from my logging:

2015-12-08T23:17:23.118817-08:00 X ? 2080 + 2080 
2015-12-08T23:17:23.119524-08:00 X = 2080 ? 4126 

The first log line: here I asked the device how many frames are available and it responds with 2080; I accordingly write 2080 frames.

The second log line: the writei() call returns 2080.  I immediately ask how many frames are available now (I usually get a small number in response ~ 20-30) but this time I get an XRUN.  I call snd_pcm_recover() and then snd_pcm_avail() again and now I get 4126 frames.

As you can see the time between these two logs is less than 1 millisecond, so I don’t understand how the PCM can go from 2080 frames available to >4096 frames available so quickly.  Is this evidence of a bug in the device driver? 

My application is using a single channel dshare PCM (rt) that has an 8-channel device underneath.  Here’s the configuration fragment:

pcm_slave.cid_dsp {
    pcm "hw:0,0"
    channels 8
    rate 44100
}

pcm.rt_channel {
    type dshare
    ipc_key 1025
    ipc_gid audio
    ipc_perm 0660
    slave cid_dsp
    bindings {
        0 5
    }
}

pcm.rt {
    type plug
    slave.pcm rt_channel
}

The underlying hardware looks like this:

access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 8
rate: 44100 (44100/1)
period_size: 1024
buffer_size: 4096

tstamp_mode: ENABLE
period_step: 1
avail_min: 1
start_threshold: 1
stop_threshold: 1073741824
silence_threshold: 0
silence_size: 0
boundary: 1073741824

Thanks for any insight and help,

Rob.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Available frames > buffer size

[Clemens Ladisch]

Rob Duncan wrote:
> Is it ever correct for snd_pcm_avail() to return a value that’s greater
> than that returned by snd_pcm_hw_params_get_buffer_size()?

Yes, but only if have disabled stop-on-underrun (by setting the
stop_threshold to the boundary value).

> the writei() call returns 2080.  I immediately ask how many frames are
> available now (I usually get a small number in response ~ 20-30) but
> this time I get an XRUN.

The XRUN state can indicate either an underrun or some other error that
makes the stream stop.  What exactly that some other error could be
depends on the driver.

> I call snd_pcm_recover() and then snd_pcm_avail() again and now I get
> 4126 frames.
>
> As you can see the time between these two logs is less than
> 1 millisecond, so I don’t understand how the PCM can go from
> 2080 frames available to >4096 frames available so quickly.

This sounds like a bug. Which version of alsa-lib are you using?


Regards,
Clemens
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Available frames > buffer size

[Rob Duncan]

On Dec 10, 2015, at 11:24 AM, Clemens Ladisch <clemens@ladisch.de> wrote:
> 
> Rob Duncan wrote:
>> Is it ever correct for snd_pcm_avail() to return a value that’s greater
>> than that returned by snd_pcm_hw_params_get_buffer_size()?
> 
> Yes, but only if have disabled stop-on-underrun (by setting the
> stop_threshold to the boundary value).

Here’s the dump of my PCM:

stream       : PLAYBACK   
access       : RW_INTERLEAVED   
format       : S16_LE   
subformat    : STD   
channels     : 1   
rate         : 44100   
exact rate   : 44100 (44100/1)   
msbits       : 16   
buffer_size  : 4096   
period_size  : 1024   
period_time  : 23219   
tstamp_mode  : NONE   
tstamp_type  : MONOTONIC   
period_step  : 1   
avail_min    : 1024   
period_event : 0   
start_threshold  : 4096   
stop_threshold   : 4096   
silence_threshold: 0   
silence_size : 0   
boundary     : 1073741824

The stop_threshold is 4096 (i.e. not the boundary).

>> I call snd_pcm_recover() and then snd_pcm_avail() again and now I get
>> 4126 frames.
>> 
>> As you can see the time between these two logs is less than
>> 1 millisecond, so I don’t understand how the PCM can go from
>> 2080 frames available to >4096 frames available so quickly.
> 
> This sounds like a bug. Which version of alsa-lib are you using?

This was done with version 1.1.0, but I also get it 1.0.23.

Thanks,

Rob.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Available frames > buffer size

[Rob Duncan]

Hi Clemens,

Thanks for responding.

On Dec 10, 2015, at 11:24 AM, Clemens Ladisch <clemens@ladisch.de<mailto:clemens@ladisch.de>> wrote:

As you can see the time between these two logs is less than
1 millisecond, so I don’t understand how the PCM can go from
2080 frames available to >4096 frames available so quickly.

This sounds like a bug. Which version of alsa-lib are you using?

Do you have any suggestions for debugging or instrumentation I can add to alsa-lib that would help me track down what’s going on?

Rob.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel