From: Raymond Yau <superquad.vortex2@gmail.com>
To: "Alexander E. Patrakov" <patrakov@gmail.com>, adam@spicenitz.org
Cc: Tanu Kaskinen <tanu.kaskinen@linux.intel.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Takashi Iwai <tiwai@suse.de>,
Clemens Ladisch <clemens@ladisch.de>,
ALSA Development Mailing List <alsa-devel@alsa-project.org>,
Arun Raghavan <arun@accosted.net>,
David Henningsson <david.henningsson@canonical.com>
Subject: Re: PulseAudio and SNDRV_PCM_INFO_BATCH
Date: Wed, 24 Jun 2015 13:51:46 +0800 [thread overview]
Message-ID: <CAN8cciYYW70PG8uf_ykK736+UdHbqyg4auzRTwGOw4+imSJuyg@mail.gmail.com> (raw)
In-Reply-To: <558837BB.4040006@gmail.com>
>> >> >>> 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).
Seem time diff vary from 2 to 4 ms
> 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
>
Avail diff can be odd number too
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
https://bugs.freedesktop.org/show_bug.cgi?id=86262
The driver does not ensure granularity must be less than period size
granularity can be larger than period size
So it is not just coarse but inaccurate
min_period_size: 6 frames, dir: 0
FIFO size is 0
Hardware PCM card 1 'Scarlett 18i8 USB' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 8
rate : 48000
exact rate : 48000 (48000/1)
msbits : 32
buffer_size : 4096
period_size : 64
period_time : 1333
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 64
period_event : 0
start_threshold : 64
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: 3 usec
Available: 66, loop iteration: 9066, diff: 9066, timestamp diff: 1395 usec
Available: 132, loop iteration: 11289, diff: 2223, timestamp diff: 1622 usec
Available: 192, loop iteration: 13351, diff: 2062, timestamp diff: 1625 usec
Available: 258, loop iteration: 15600, diff: 2249, timestamp diff: 1625 usec
Available: 325, loop iteration: 17822, diff: 2222, timestamp diff: 1625 usec
Available: 385, loop iteration: 20092, diff: 2270, timestamp diff: 1626 usec
Available: 451, loop iteration: 22045, diff: 1953, timestamp diff: 1625 usec
Available: 512, loop iteration: 24239, diff: 2194, timestamp diff: 1630 usec
Available: 578, loop iteration: 26305, diff: 2066, timestamp diff: 1619 usec
Available: 644, loop iteration: 28447, diff: 2142, timestamp diff: 1626 usec
next prev parent reply other threads:[~2015-06-24 5:51 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
2015-06-24 5:51 ` Raymond Yau [this message]
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=CAN8cciYYW70PG8uf_ykK736+UdHbqyg4auzRTwGOw4+imSJuyg@mail.gmail.com \
--to=superquad.vortex2@gmail.com \
--cc=adam@spicenitz.org \
--cc=alsa-devel@alsa-project.org \
--cc=arun@accosted.net \
--cc=clemens@ladisch.de \
--cc=david.henningsson@canonical.com \
--cc=lars@metafoo.de \
--cc=patrakov@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.