From: "Alexander E. Patrakov" <patrakov@gmail.com>
To: Raymond Yau <superquad.vortex2@gmail.com>
Cc: ALSA Development Mailing List <alsa-devel@alsa-project.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Takashi Iwai <tiwai@suse.de>,
Clemens Ladisch <clemens@ladisch.de>,
Tanu Kaskinen <tanu.kaskinen@linux.intel.com>,
Arun Raghavan <arun@accosted.net>,
David Henningsson <david.henningsson@canonical.com>
Subject: Re: PulseAudio and SNDRV_PCM_INFO_BATCH
Date: Mon, 22 Jun 2015 21:28:43 +0500 [thread overview]
Message-ID: <558837BB.4040006@gmail.com> (raw)
In-Reply-To: <CAN8ccib_DS2kOLzHCj8v_H90VqNZsCk4h_4Gb6Vkb=nQw30L_w@mail.gmail.com>
22.06.2015 20:50, Raymond Yau wrote:
> >>
> >> >>>
> >> >>> The ALSA API requires the driver to provide a cyclic sample
> buffer (or
> >> >>> something that behaves like one).
> >> >>>
> >> >>> However, not all hardware works this way. USB and FireWire
> require the
> >> >>> driver to continually queue new packets, whose size and timing are
> >> >>> determined by the bus clock and are not directly related to the
> ALSA
> >> >>> ring buffer. These drivers use double buffering; the actual DMA
> >> happens
> >> >>> from those packets, not from the ring buffer.
> >> >>>
> >> >>
> >> >> If those queued packets/urb cannot be rewind, snd_pcm_rewindable
> should
> >> >> return zero for those driver
> >> >
> >> >
> >> > Not really.
> >> >
> >> > As I understand it, the kernel periodically converts a piece of the
> >> ring buffer (located in RAM) into an URB, and it gets sent through the
> >> USB bus. Parts of the buffer that are not yet converted to URB are
> >> perfectly rewindable.
> >> >
> >> > In other words, for USB devices, the kernel already implements the
> >> "low-latency background thread that makes unrewindable devices
> >> rewindable" idea that I discussed (as a strawman proposal) here for
> >> userspace:
> >> >
> >> >
> >>
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/080868.html
> >> >
> >>
> >> This mean that SNDRV_PCM_INFO_BATCH represent exact one period is not
> >> correct for usb and firewire since hw_ptr does not increment in
> period size
> >
> >
> > Well, according to the new definition, "SNDRV_PCM_INFO_BATCH on the
> other hand has become to mean that the device is only capable of
> reporting the audio pointer with a coarse granularity". In the USB case,
> we indeed have coarse granularity (6 ms in the worst case), but not as
> bad as one period.
> >
> >
> >>
> >> Do this mean .period_bytes_min of snd-usb-audio is incorrect since
> >> .period_bytes_min should be at least size of urb/packet ?
> >>
> >
> > I don't see anything wrong here. With the USB device that my
> colleague has here at work, the minimum period size is 48 samples, i.e.
> 1 ms, which looks exactly like one USB data packet.
> >
>
> What is the smallest buffer time which your usb audio can playback
> without underrun using aplay with two periods (2ms or 12ms) ?
>
That device is at work, and is not mine. So, the test below has been
done with a different USB device that I have at home, namely, ROTEL
RA-1570 integrated amplifier. It has a menu option to select either 1.0
or 2.0 USB audio class, I have set it to 1.0 to match that C-Media
device. By default, with large-enough period size, it has avail
granularity that jumps between 3 and 4 ms, and delay granularity of 1 ms
(even if I select a better period size, like 960 frames).
======= testing hw:3 =======
min_period_size: 48 frames, dir: 0
FIFO size is 0
Hardware PCM card 3 'Rotel PC-USB' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 4096
period_size : 1024
period_time : 21333
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 1024
period_event : 0
start_threshold : 1024
stop_threshold : 4096
silence_threshold: 0
silence_size : 0
boundary : 4611686018427387904
appl_ptr : 0
hw_ptr : 0
Playing silence
Available: 0, loop iteration: 0, diff: 0, timestamp diff: 1 usec
Available: 192, loop iteration: 32070, diff: 32070, timestamp diff: 3923
usec
Available: 336, loop iteration: 37315, diff: 5245, timestamp diff: 4003 usec
Available: 480, loop iteration: 42710, diff: 5395, timestamp diff: 3999 usec
Available: 624, loop iteration: 48292, diff: 5582, timestamp diff: 3999 usec
Available: 768, loop iteration: 53880, diff: 5588, timestamp diff: 4000 usec
Available: 912, loop iteration: 57858, diff: 3978, timestamp diff: 3000 usec
Available: 1056, loop iteration: 62125, diff: 4267, timestamp diff: 3000
usec
Available: 1200, loop iteration: 66536, diff: 4411, timestamp diff: 3000
usec
Available: 1344, loop iteration: 70679, diff: 4143, timestamp diff: 3001
usec
Available: 1488, loop iteration: 75091, diff: 4412, timestamp diff: 2999
usec
Available: 1632, loop iteration: 79368, diff: 4277, timestamp diff: 3000
usec
Available: 1776, loop iteration: 83675, diff: 4307, timestamp diff: 3000
usec
Available: 1920, loop iteration: 87964, diff: 4289, timestamp diff: 3000
usec
Available: 2064, loop iteration: 92384, diff: 4420, timestamp diff: 2999
usec
Available: 2208, loop iteration: 96638, diff: 4254, timestamp diff: 3001
usec
Available: 2353, loop iteration: 100900, diff: 4262, timestamp diff:
3010 usec
Available: 2497, loop iteration: 105000, diff: 4100, timestamp diff:
2991 usec
Available: 2641, loop iteration: 109291, diff: 4291, timestamp diff:
2999 usec
Available: 2785, loop iteration: 113714, diff: 4423, timestamp diff:
3000 usec
Available: 2977, loop iteration: 117955, diff: 4241, timestamp diff:
3000 usec
Available: 3074, loop iteration: 122323, diff: 4368, timestamp diff:
2999 usec
Available: 3266, loop iteration: 126556, diff: 4233, timestamp diff:
3001 usec
Available: 3410, loop iteration: 130983, diff: 4427, timestamp diff:
3000 usec
Available: 3554, loop iteration: 136790, diff: 5807, timestamp diff:
4000 usec
Available: 3698, loop iteration: 139699, diff: 2909, timestamp diff:
2000 usec
Available: 3842, loop iteration: 145320, diff: 5621, timestamp diff:
4000 usec
Available: 3986, loop iteration: 149502, diff: 4182, timestamp diff:
3000 usec
This command produces no xruns with a 48 kHz stereo S16_LE file:
aplay --buffer-size 96 --period-size 48 -D hw:3 test1.wav
$ cat /proc/asound/PCUSB/pcm0p/sub0/info
card: 3
device: 0
subdevice: 0
stream: PLAYBACK
id: USB Audio
name: USB Audio
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0
$ cat /proc/asound/PCUSB/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 48
buffer_size: 96
$ cat /proc/asound/PCUSB/pcm0p/sub0/sw_params
tstamp_mode: NONE
period_step: 1
avail_min: 48
start_threshold: 96
stop_threshold: 96
silence_threshold: 0
silence_size: 0
boundary: 6917529027641081856
After several minutes, aplay did not report any xruns, and the sound is
still clean:
$ cat /proc/asound/PCUSB/pcm0p/sub0/status
state: RUNNING
owner_pid : 2505
trigger_time: 4025.921768556
tstamp : 0.000000000
delay : 145
avail : 0
avail_max : 48
-----
hw_ptr : 25506151
appl_ptr : 25506247
The minimum reported period size at 48 kHz is 48 frames.
--
Alexander E. Patrakov
next prev parent reply other threads:[~2015-06-22 16:28 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 12:29 PulseAudio and SNDRV_PCM_INFO_BATCH Arun Raghavan
2015-06-12 12:32 ` Arun Raghavan
2015-06-12 13:43 ` Alexander E. Patrakov
2015-06-12 13:57 ` Alexander E. Patrakov
2015-06-17 3:04 ` Raymond Yau
2015-06-17 3:38 ` Alexander E. Patrakov
2015-06-15 3:42 ` Raymond Yau
2015-06-15 8:03 ` Lars-Peter Clausen
2015-06-15 11:39 ` Raymond Yau
2015-06-15 12:01 ` Lars-Peter Clausen
2015-06-15 13:34 ` Raymond Yau
2015-06-15 14:16 ` Lars-Peter Clausen
2015-06-16 2:33 ` Raymond Yau
2015-06-17 8:27 ` Lars-Peter Clausen
2015-06-17 9:19 ` Takashi Iwai
2015-06-17 15:09 ` David Henningsson
2015-06-17 16:48 ` Alexander E. Patrakov
2015-06-18 3:15 ` Raymond Yau
2015-06-19 11:19 ` Alexander E. Patrakov
2015-06-19 1:17 ` Raymond Yau
2015-06-19 11:32 ` Takashi Iwai
2015-06-20 3:24 ` Raymond Yau
2015-06-20 6:17 ` Raymond Yau
2015-06-22 2:35 ` Raymond Yau
2015-06-22 6:43 ` Lars-Peter Clausen
2015-06-22 7:49 ` Raymond Yau
2015-06-22 9:41 ` Clemens Ladisch
2015-06-22 11:54 ` Raymond Yau
2015-06-22 12:10 ` Alexander E. Patrakov
2015-06-22 12:34 ` Raymond Yau
2015-06-22 12:49 ` Alexander E. Patrakov
2015-06-22 15:50 ` Raymond Yau
2015-06-22 16:28 ` Alexander E. Patrakov [this message]
2015-06-24 5:51 ` Raymond Yau
2015-06-22 22:52 ` Takashi Sakamoto
2015-06-27 15:28 ` Alexander E. Patrakov
2015-06-27 17:15 ` Clemens Ladisch
2015-06-27 17:58 ` Alexander E. Patrakov
2015-06-28 2:09 ` Raymond Yau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=558837BB.4040006@gmail.com \
--to=patrakov@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=arun@accosted.net \
--cc=clemens@ladisch.de \
--cc=david.henningsson@canonical.com \
--cc=lars@metafoo.de \
--cc=superquad.vortex2@gmail.com \
--cc=tanu.kaskinen@linux.intel.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.