All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.