* Available frames > buffer size
@ 2015-12-10 14:48 Rob Duncan
2015-12-10 19:24 ` Clemens Ladisch
0 siblings, 1 reply; 4+ messages in thread
From: Rob Duncan @ 2015-12-10 14:48 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Available frames > buffer size
2015-12-10 14:48 Available frames > buffer size Rob Duncan
@ 2015-12-10 19:24 ` Clemens Ladisch
2015-12-10 21:24 ` Rob Duncan
2015-12-11 18:47 ` Rob Duncan
0 siblings, 2 replies; 4+ messages in thread
From: Clemens Ladisch @ 2015-12-10 19:24 UTC (permalink / raw)
To: Rob Duncan, alsa-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Available frames > buffer size
2015-12-10 19:24 ` Clemens Ladisch
@ 2015-12-10 21:24 ` Rob Duncan
2015-12-11 18:47 ` Rob Duncan
1 sibling, 0 replies; 4+ messages in thread
From: Rob Duncan @ 2015-12-10 21:24 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Available frames > buffer size
2015-12-10 19:24 ` Clemens Ladisch
2015-12-10 21:24 ` Rob Duncan
@ 2015-12-11 18:47 ` Rob Duncan
1 sibling, 0 replies; 4+ messages in thread
From: Rob Duncan @ 2015-12-11 18:47 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-12-11 18:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-10 14:48 Available frames > buffer size Rob Duncan
2015-12-10 19:24 ` Clemens Ladisch
2015-12-10 21:24 ` Rob Duncan
2015-12-11 18:47 ` Rob Duncan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.