PulseAudio and SNDRV_PCM_INFO_BATCH

PulseAudio and SNDRV_PCM_INFO_BATCH

[Arun Raghavan]

Hi folks,
I'd like to bring this one up again, since we are currently in the
sub-optimal position of forcing ~100 ms latency on USB devices. The
original thread is here --
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.html

I see two flags that are possibly of consequence here:
SNDRV_PCM_INFO_BATCH and SNDRV_PCM_INFO_BLOCK_TRANSFER. I'm not sure
what these mean -- the documentation mentions "double buffering" for
the batch flag, and just that the block transfer means "block
transfer". :-)

We've spoken about batch meaning either transfers in period size
chunks, or some fixed chunk size. It seems that it would make more
sense for it to mean the former, and block transfer to mean the
latter.

So I guess the first thing that would be nice to have is a clear
meaning of these two flags. With this done, we could potentially get
to the API to report the transfer size from the driver.

I did notice that there is a snd_pcm_hw_params_get_fifo_size(). Is
this something we could use for the purpose of transfer size
reporting, by any chance?

Cheers,
Arun

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Arun Raghavan]

On 12 June 2015 at 17:59, Arun Raghavan <arun@accosted.net> wrote:
> Hi folks,
> I'd like to bring this one up again, since we are currently in the
> sub-optimal position of forcing ~100 ms latency on USB devices. The
> original thread is here --
> http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.html

While we sort this out, though, is there an upper bound on the USB
transfer size (that we could then use a rewind safety margin)? We
might be able to use this as a workaround till this can be fixed
properly.

-- Arun

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Alexander E. Patrakov]

[-- Attachment #1: Type: text/plain, Size: 3330 bytes --]

12.06.2015 17:32, Arun Raghavan wrote:
> On 12 June 2015 at 17:59, Arun Raghavan <arun@accosted.net> wrote:
>> Hi folks,
>> I'd like to bring this one up again, since we are currently in the
>> sub-optimal position of forcing ~100 ms latency on USB devices. The
>> original thread is here --
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.html
>
> While we sort this out, though, is there an upper bound on the USB
> transfer size (that we could then use a rewind safety margin)? We
> might be able to use this as a workaround till this can be fixed
> properly.

Hello Arun,

thanks for bringing up the issue again. However, I think that the "~100 
ms latency on batch cards" problem can and should also be solved from 
the other end, independently from the USB special case. Namely, I think 
that the default buffer and period sizes that PulseAudio selects are way 
too conservative. The power-saving argument was used in the past as a 
justification, and I am calling for a reevaluation. Here is why.

1. Android's AudioFlinger uses 2 periods, 5 ms each. It is a mobile OS, 
and the developers think it is good enough.

2. I have measured the battery life time of my SandyBridge-based laptop 
and found that, with pure ALSA on the hw:0 device, a similar low-latency 
setup loses less than 5% of the battery life (935 seconds were lost out 
of 25742). With PulseAudio, the difference is worse, but let's treat 
this as a missed optimization in PulseAudio.

Let me make my viewpoint more explicit: from now on, I will reject CPU 
usage measurements as an evidence for "real power-saving problems", 
unless a correlation factor between them and the battery life has been 
also measured on the same device. Direct measurements of the battery 
life in reproducible conditions are of course welcome.

Raw data for the experiment (2) with pure ALSA are attached. The first 
column is the time since boot, in seconds, and the second column is the 
remaining energy in the battery, in microwatt-hours, as reported in the 
energy_now sysfs attribute. report-1428125745.txt is with 
--period-size=44100 --buffer-size=88200, report-1428161181.txt is with 
--buffer-size=440 --period-size=220, the test file is a 44100 Hz, S16, 
stereo wav file.

To guarantee the reproducibility of this experiment, the entire system 
(Gentoo stage3 plus PulseAudio plus laptop-mode-tools) has been put in 
the initramfs, together with a script that turns off the backlight and 
then repeatedly plays a wav file from the same initramfs through aplay. 
The wi-fi card has been turned off with a hardware toggle. So everything 
(including the SSD) during the test is unused, except CPU, memory, and 
the onboard sound card. That's why the test exhibits unrealistically 
long battery life.

If my result gets confirmed on a laptop that is not a former flagman 
from Sony, then I would argue for the following:

1. Change of the default buffer and period sizes for batch cards in 
PulseAudio to values that represent, on modern hardware, say, 2.5% of 
battery life reduction as compared to very large periods.

2. Limiting of the sleep time in the timer-based scheduling logic to a 
similar value. If this ends up below 30 ms, then we can simplify 
PulseAudio by removing all traces of the rewind logic.

-- 
Alexander E. Patrakov

[-- Attachment #2: report-1428125745.txt --]
[-- Type: text/plain, Size: 4922 bytes --]

5 38590000
80 38590000
155 38590000
230 38590000
305 38590000
380 38590000
456 38590000
531 38590000
606 38590000
681 38590000
756 38590000
831 38540000
906 38450000
981 38380000
1056 38310000
1131 38220000
1206 38150000
1281 38080000
1356 37980000
1431 37920000
1506 37850000
1581 37750000
1656 37710000
1731 37620000
1806 37570000
1881 37500000
1956 37410000
2031 37360000
2106 37270000
2181 37220000
2256 37130000
2331 37060000
2406 37000000
2481 36920000
2556 36850000
2631 36790000
2706 36720000
2781 36640000
2856 36550000
2931 36510000
3006 36410000
3082 36360000
3157 36230000
3232 36090000
3307 35910000
3382 35790000
3457 35680000
3532 35490000
3607 35380000
3682 35190000
3757 35060000
3832 34890000
3907 34740000
3982 34630000
4057 34510000
4132 34330000
4207 34210000
4282 34100000
4357 33910000
4432 33800000
4507 33680000
4582 33520000
4657 33380000
4732 33240000
4807 33120000
4882 32970000
4957 32760000
5032 32710000
5107 32590000
5182 32480000
5258 32330000
5333 32220000
5408 32100000
5483 31990000
5558 31880000
5633 31690000
5708 31550000
5783 31440000
5858 31310000
5933 31200000
6008 31090000
6083 30950000
6158 30840000
6233 30710000
6308 30600000
6383 30460000
6458 30350000
6533 30230000
6608 30110000
6683 30000000
6758 29810000
6833 29690000
6908 29580000
6983 29470000
7058 29330000
7133 29220000
7208 29070000
7283 28960000
7358 28840000
7434 28730000
7509 28600000
7584 28470000
7659 28350000
7734 28240000
7809 28130000
7884 27980000
7959 27870000
8034 27750000
8109 27640000
8184 27520000
8259 27380000
8334 27220000
8409 27080000
8484 26960000
8559 26850000
8634 26730000
8709 26550000
8784 26430000
8859 26320000
8934 26170000
9009 26060000
9084 25870000
9159 25720000
9234 25570000
9309 25460000
9384 25270000
9459 25160000
9534 24740000
9610 24600000
9685 24490000
9760 24380000
9835 24140000
9910 23930000
9985 23720000
10060 23510000
10135 23230000
10210 22980000
10285 22780000
10360 22570000
10435 22330000
10510 22120000
10585 22010000
10660 21800000
10735 21590000
10810 21380000
10885 21290000
10960 21060000
11035 20760000
11110 20520000
11185 20350000
11260 20200000
11335 20110000
11410 19900000
11485 19790000
11560 19690000
11635 19580000
11711 19370000
11786 19260000
11861 19050000
11936 18950000
12011 18840000
12086 18730000
12161 18510000
12236 18390000
12311 18300000
12386 18190000
12461 18090000
12536 17880000
12611 17860000
12686 17770000
12761 17560000
12836 17490000
12911 17350000
12986 17330000
13061 17240000
13136 17130000
13211 17010000
13286 16920000
13361 16870000
13436 16770000
13511 16710000
13586 16590000
13661 16590000
13736 16450000
13811 16380000
13886 16380000
13962 16170000
14037 16060000
14112 15960000
14187 15960000
14262 15850000
14337 15730000
14412 15680000
14487 15640000
14562 15640000
14637 15530000
14712 15430000
14787 15430000
14862 15320000
14937 15230000
15012 15170000
15087 15110000
15162 15020000
15237 15000000
15312 14900000
15387 14900000
15462 14790000
15537 14790000
15612 14700000
15687 14570000
15762 14510000
15837 14460000
15912 14360000
15987 14270000
16063 14250000
16138 14130000
16213 14040000
16288 13930000
16363 13850000
16438 13830000
16513 13720000
16588 13630000
16663 13550000
16738 13510000
16813 13440000
16888 13400000
16963 13350000
17038 13300000
17113 13230000
17188 13160000
17263 13120000
17338 13020000
17413 12980000
17488 12910000
17563 12790000
17638 12630000
17713 12540000
17788 12470000
17863 12380000
17938 12310000
18013 12210000
18088 12120000
18163 12010000
18239 11930000
18314 11820000
18389 11700000
18464 11610000
18539 11500000
18614 11380000
18689 11240000
18764 11120000
18839 11010000
18914 10890000
18989 10760000
19064 10480000
19139 10360000
19214 10250000
19289 10080000
19364 9920000
19439 9760000
19514 9650000
19589 9480000
19664 9370000
19739 9200000
19814 9050000
19889 8880000
19964 8710000
20039 8580000
20114 8440000
20189 8180000
20264 8050000
20339 7900000
20415 7840000
20490 7700000
20565 7560000
20640 7450000
20715 7350000
20790 7220000
20865 7120000
20940 7000000
21015 6860000
21090 6730000
21165 6600000
21240 6520000
21315 6380000
21390 6280000
21465 6130000
21540 6030000
21615 5890000
21690 5790000
21765 5680000
21840 5590000
21915 5450000
21990 5320000
22065 5190000
22140 5060000
22215 4960000
22290 4850000
22365 4710000
22440 4570000
22516 4480000
22591 4320000
22666 4230000
22741 4110000
22816 3970000
22891 3830000
22966 3740000
23041 3670000
23116 3620000
23191 3550000
23266 3490000
23341 3420000
23416 3340000
23491 3300000
23566 3250000
23641 3160000
23716 3090000
23791 3040000
23866 3000000
23941 2930000
24016 2850000
24091 2810000
24166 2740000
24241 2700000
24316 2630000
24391 2550000
24466 2510000
24541 2420000
24616 2350000
24692 2250000
24767 2210000
24842 2100000
24917 2000000
24992 1910000
25067 1800000
25142 1650000
25217 1610000
25292 1540000
25367 1470000
25442 1400000
25517 1310000
25592 1190000
25667 1080000
25742 930000

[-- Attachment #3: report-1428161181.txt --]
[-- Type: text/plain, Size: 4760 bytes --]

5 38590000
80 38590000
155 38590000
229 38590000
304 38590000
379 38590000
454 38590000
528 38590000
603 38590000
678 38590000
752 38590000
827 38590000
902 38520000
976 38450000
1051 38360000
1126 38260000
1200 38200000
1275 38130000
1350 38030000
1425 37960000
1499 37870000
1574 37810000
1649 37710000
1723 37660000
1798 37570000
1873 37500000
1947 37410000
2022 37340000
2097 37270000
2172 37200000
2246 37110000
2321 37060000
2396 36960000
2470 36870000
2545 36830000
2620 36740000
2694 36640000
2769 36600000
2844 36510000
2919 36460000
2993 36360000
3068 36190000
3143 36060000
3217 35880000
3292 35720000
3367 35580000
3441 35460000
3516 35280000
3591 35120000
3666 34980000
3740 34870000
3815 34680000
3890 34570000
3964 34380000
4039 34250000
4114 34080000
4188 33950000
4263 33800000
4338 33660000
4413 33540000
4487 33360000
4562 33240000
4637 33120000
4711 33010000
4786 32870000
4861 32710000
4936 32570000
5010 32460000
5085 32330000
5160 32220000
5234 32030000
5309 31920000
5384 31800000
5458 31670000
5533 31550000
5608 31390000
5683 31310000
5757 31140000
5832 31010000
5907 30900000
5981 30760000
6056 30650000
6131 30540000
6205 30410000
6280 30230000
6355 30110000
6430 29970000
6504 29860000
6579 29750000
6654 29600000
6728 29510000
6803 29390000
6878 29220000
6953 29090000
7027 28980000
7102 28840000
7177 28730000
7251 28600000
7326 28490000
7401 28370000
7475 28190000
7550 28130000
7625 28010000
7700 27850000
7774 27750000
7849 27590000
7924 27450000
7998 27340000
8073 27220000
8148 27060000
8222 26920000
8297 26810000
8372 26680000
8447 26510000
8521 26380000
8596 26200000
8671 26090000
8745 25900000
8820 25790000
8895 25640000
8970 25490000
9044 25300000
9119 24930000
9194 24760000
9268 24630000
9343 24460000
9418 24320000
9492 24120000
9567 23810000
9642 23600000
9717 23380000
9791 23170000
9866 22870000
9941 22630000
10015 22420000
10090 22210000
10165 22000000
10239 21840000
10314 21630000
10389 21470000
10464 21270000
10538 21150000
10613 20720000
10688 20630000
10762 20420000
10837 20310000
10912 20100000
10986 19990000
11061 19780000
11136 19660000
11211 19570000
11285 19360000
11360 19250000
11435 19080000
11509 18950000
11584 18830000
11659 18710000
11734 18500000
11808 18410000
11883 18290000
11958 18180000
12032 18090000
12107 17970000
12182 17880000
12256 17780000
12331 17560000
12406 17460000
12481 17420000
12555 17350000
12630 17230000
12705 17090000
12779 17030000
12854 16910000
12929 16910000
13003 16820000
13078 16690000
13153 16610000
13228 16560000
13302 16520000
13377 16310000
13452 16180000
13526 16180000
13601 16070000
13676 15960000
13751 15960000
13825 15860000
13900 15750000
13975 15710000
14049 15650000
14124 15610000
14199 15540000
14273 15450000
14348 15430000
14423 15330000
14498 15220000
14572 15220000
14647 15120000
14722 15120000
14796 15010000
14871 14920000
14946 14900000
15020 14800000
15095 14710000
15170 14690000
15245 14560000
15319 14470000
15394 14430000
15469 14360000
15543 14260000
15618 14170000
15693 14060000
15768 13940000
15842 13940000
15917 13850000
15992 13730000
16066 13690000
16141 13620000
16216 13580000
16290 13500000
16365 13450000
16440 13390000
16515 13300000
16589 13220000
16664 13180000
16739 13110000
16813 13020000
16888 12940000
16963 12740000
17037 12670000
17112 12620000
17187 12510000
17262 12390000
17336 12300000
17411 12230000
17486 12110000
17560 12000000
17635 11910000
17710 11790000
17784 11680000
17859 11580000
17934 11440000
18009 11300000
18083 11190000
18158 11040000
18233 10910000
18307 10790000
18382 10510000
18457 10400000
18532 10230000
18606 10090000
18681 9910000
18756 9750000
18830 9590000
18905 9470000
18980 9310000
19054 9150000
19129 8960000
19204 8800000
19279 8640000
19353 8470000
19428 8360000
19503 8100000
19577 7980000
19652 7850000
19727 7700000
19801 7640000
19876 7490000
19951 7360000
20026 7240000
20100 7100000
20175 7020000
20250 6890000
20324 6760000
20399 6620000
20474 6500000
20549 6360000
20623 6270000
20698 6110000
20773 6020000
20847 5870000
20922 5760000
20997 5620000
21071 5550000
21146 5420000
21221 5270000
21296 5140000
21370 5020000
21445 4930000
21520 4780000
21594 4670000
21669 4530000
21744 4420000
21818 4270000
21893 4140000
21968 4020000
22043 3890000
22117 3800000
22192 3720000
22267 3650000
22341 3610000
22416 3540000
22491 3460000
22566 3400000
22640 3330000
22715 3260000
22790 3190000
22864 3140000
22939 3070000
23014 3010000
23088 2930000
23163 2860000
23238 2820000
23313 2750000
23387 2680000
23462 2610000
23537 2540000
23611 2450000
23686 2380000
23761 2310000
23835 2220000
23910 2120000
23985 2010000
24060 1920000
24134 1800000
24209 1670000
24284 1590000
24358 1520000
24433 1480000
24508 1390000
24582 1290000
24657 1180000
24732 1030000
24807 900000

[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Alexander E. Patrakov]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

sorry, I need to clarify some of my words

12.06.2015 18:43, Alexander E. Patrakov wrote:
> To guarantee the reproducibility of this experiment, the entire system
> (Gentoo stage3 plus PulseAudio plus laptop-mode-tools) has been put in
> the initramfs,

Clarification due to a possible "why PulseAudio" question. I have 
actually reused an old initramfs that I put together in order to measure 
the effect of various resamplers on battery life. Result back then: with 
1s latency, when resampling from 44.1 to 48 kHz, speex-float-5 robs 734 
seconds of battery life, out of 26731, as compared to speex-float-1. 
I.e. less than the battery lost due to 6 months of aging.

The scripts are attached, measure.sh is called from a script in 
/etc/local.d.

> 2. Limiting of the sleep time in the timer-based scheduling logic to a
> similar value. If this ends up below 30 ms, then we can simplify
> PulseAudio by removing all traces of the rewind logic.

I should point out that CRAS (another sound server that implements 
timer-based scheduling, from ChromeOS) has no rewind logic at all, and 
relies on clients not to request insanely large buffer size. Also, it 
contains no batch-card logic.

-- 
Alexander E. Patrakov

[-- Attachment #2: measure.sh --]
[-- Type: application/x-shellscript, Size: 1085 bytes --]

[-- Attachment #3: aplay.sh --]
[-- Type: application/x-shellscript, Size: 113 bytes --]

[-- Attachment #4: paplay.sh --]
[-- Type: application/x-shellscript, Size: 56 bytes --]

[-- Attachment #5: Type: text/plain, Size: 0 bytes --]

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

> > I'd like to bring this one up again, since we are currently in the
> > sub-optimal position of forcing ~100 ms latency on USB devices. The
> > original thread is here --
> >
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.html
>
> While we sort this out, though, is there an upper bound on the USB
> transfer size (that we could then use a rewind safety margin)? We
> might be able to use this as a workaround till this can be fixed
> properly.

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/usb?id=976b6c064a957445eb0573b270f2d0282630e9b9

Seem there are differences between high speed devices and others

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/usb?id=a93455e1c301ce2a4cae11682359fd2067a8fd30

Do usb wireless audio different from others ?

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Lars-Peter Clausen]

On 06/12/2015 02:29 PM, Arun Raghavan wrote:
> Hi folks,
> I'd like to bring this one up again, since we are currently in the
> sub-optimal position of forcing ~100 ms latency on USB devices. The
> original thread is here --
> http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.html
>
> I see two flags that are possibly of consequence here:
> SNDRV_PCM_INFO_BATCH and SNDRV_PCM_INFO_BLOCK_TRANSFER. I'm not sure
> what these mean -- the documentation mentions "double buffering" for
> the batch flag, and just that the block transfer means "block
> transfer". :-)
>
> We've spoken about batch meaning either transfers in period size
> chunks, or some fixed chunk size. It seems that it would make more
> sense for it to mean the former, and block transfer to mean the
> latter.
>
> So I guess the first thing that would be nice to have is a clear
> meaning of these two flags. With this done, we could potentially get
> to the API to report the transfer size from the driver.

Yeah, the meaning of those flags is somewhat fuzzy and may have changed over 
time as well. Here is my understanding of the flags, might not necessarily 
be 100% correct.

SNDRV_PCM_INFO_BLOCK_TRANSFER means that the data is copied from the user 
accessible buffer in blocks of one period. Typically these kinds of devices 
have some dedicated audio memory that is not accessible via normal memory 
access and a DMA is setup to copy data from main memory to the dedicated 
memory. This DMA transfers the data from the main memory to the dedicated 
memory in chunks of period size. But otherwise the controller might still be 
capable of reporting a accurate pointer position down to the sample/frame level.

So SNDRV_PCM_INFO_BLOCK_TRANSFER is mainly important for rewind handling and 
devices with that flag set might need additional headroom since the data up 
to one period after the pointer position has already been copied to the 
dedicated memory and hence can no longer be overwritten.

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. 
Typically this means a period sized granularity, but there are some other 
cases as well.

>
> I did notice that there is a snd_pcm_hw_params_get_fifo_size(). Is
> this something we could use for the purpose of transfer size
> reporting, by any chance?

I think the idea with fifo_size() is mainly to aide with audio latency 
measurement. I.e. how many samples before the pointer() position are still 
inside the audio pipeline and have not yet reached the analog domain. But 
since there are now users that rely on it a lot of driver don't really 
bothered with setting it to the correct value. And for the use case here 
data is on the wrong side of the pointer() value as well. What we need is 
some kind of indication of the fuzziness of the pointer() value. E.g. how 
far can it be away from the actual position in the stream.

- Lars

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>>
>> Hi folks,
>> I'd like to bring this one up again, since we are currently in the
>> sub-optimal position of forcing ~100 ms latency on USB devices. The
>> original thread is here --
>>
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.html
>>
>> I see two flags that are possibly of consequence here:
>> SNDRV_PCM_INFO_BATCH and SNDRV_PCM_INFO_BLOCK_TRANSFER. I'm not sure
>> what these mean -- the documentation mentions "double buffering" for
>> the batch flag, and just that the block transfer means "block
>> transfer". :-)
>>
>> We've spoken about batch meaning either transfers in period size
>> chunks, or some fixed chunk size. It seems that it would make more
>> sense for it to mean the former, and block transfer to mean the
>> latter.
>>
>> So I guess the first thing that would be nice to have is a clear
>> meaning of these two flags. With this done, we could potentially get
>> to the API to report the transfer size from the driver.
>
>
> Yeah, the meaning of those flags is somewhat fuzzy and may have changed
over time as well. Here is my understanding of the flags, might not
necessarily be 100% correct.
>
> SNDRV_PCM_INFO_BLOCK_TRANSFER means that the data is copied from the user
accessible buffer in blocks of one period. Typically these kinds of devices
have some dedicated audio memory that is not accessible via normal memory
access and a DMA is setup to copy data from main memory to the dedicated
memory. This DMA transfers the data from the main memory to the dedicated
memory in chunks of period size. But otherwise the controller might still
be capable of reporting a accurate pointer position down to the
sample/frame level.
>
> So SNDRV_PCM_INFO_BLOCK_TRANSFER is mainly important for rewind handling
and devices with that flag set might need additional headroom since the
data up to one period after the pointer position has already been copied to
the dedicated memory and hence can no longer be overwritten.
>
> 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.
Typically this means a period sized granularity, but there are some other
cases as well.
>

DSP_CAP_REALTIME bit tells if the device/operating system supports precise
reporting of output pointer position using SNDCTL_DSP_GETxPTR. Precise
means that accuracy of the reported playback pointer (time) is around few
samples. Without this capability the playback/recording position is
reported using precision of one fragment.

DSP_CAP_BATCH bit means that the device has some kind of local storage for
recording and/or playback. For this reason the information reported by
SNDCTL_DSP_GETxPTR is very inaccurate.

Are those alsa cap have the similar meaning of those oss cap ?

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Lars-Peter Clausen]

On 06/15/2015 01:39 PM, Raymond Yau wrote:
>>>
>>> Hi folks,
>>> I'd like to bring this one up again, since we are currently in the
>>> sub-optimal position of forcing ~100 ms latency on USB devices. The
>>> original thread is here --
>>>
> http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.html
>>>
>>> I see two flags that are possibly of consequence here:
>>> SNDRV_PCM_INFO_BATCH and SNDRV_PCM_INFO_BLOCK_TRANSFER. I'm not sure
>>> what these mean -- the documentation mentions "double buffering" for
>>> the batch flag, and just that the block transfer means "block
>>> transfer". :-)
>>>
>>> We've spoken about batch meaning either transfers in period size
>>> chunks, or some fixed chunk size. It seems that it would make more
>>> sense for it to mean the former, and block transfer to mean the
>>> latter.
>>>
>>> So I guess the first thing that would be nice to have is a clear
>>> meaning of these two flags. With this done, we could potentially get
>>> to the API to report the transfer size from the driver.
>>
>>
>> Yeah, the meaning of those flags is somewhat fuzzy and may have changed
> over time as well. Here is my understanding of the flags, might not
> necessarily be 100% correct.
>>
>> SNDRV_PCM_INFO_BLOCK_TRANSFER means that the data is copied from the user
> accessible buffer in blocks of one period. Typically these kinds of devices
> have some dedicated audio memory that is not accessible via normal memory
> access and a DMA is setup to copy data from main memory to the dedicated
> memory. This DMA transfers the data from the main memory to the dedicated
> memory in chunks of period size. But otherwise the controller might still
> be capable of reporting a accurate pointer position down to the
> sample/frame level.
>>
>> So SNDRV_PCM_INFO_BLOCK_TRANSFER is mainly important for rewind handling
> and devices with that flag set might need additional headroom since the
> data up to one period after the pointer position has already been copied to
> the dedicated memory and hence can no longer be overwritten.
>>
>> 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.
> Typically this means a period sized granularity, but there are some other
> cases as well.
>>
>
> DSP_CAP_REALTIME bit tells if the device/operating system supports precise
> reporting of output pointer position using SNDCTL_DSP_GETxPTR. Precise
> means that accuracy of the reported playback pointer (time) is around few
> samples. Without this capability the playback/recording position is
> reported using precision of one fragment.
>
> DSP_CAP_BATCH bit means that the device has some kind of local storage for
> recording and/or playback. For this reason the information reported by
> SNDCTL_DSP_GETxPTR is very inaccurate.
>
> Are those alsa cap have the similar meaning of those oss cap ?

I would say historically SNDRV_PCM_INFO_BATCH had the same meaning as 
DSP_CAP_BATCH, but it has also come to have the inverse meaning to 
DSP_CAP_REALTIME. By default applications can assume that the pointer is 
accurate down to a few samples, but if SNDRV_PCM_INFO_BATCH is set it is 
less accurate and can be everything up to period size precession.

SNDRV_PCM_INFO_BLOCK_TRANSFER is different from all of them though.

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>>>>
>>>>
>>>> Hi folks,
>>>> I'd like to bring this one up again, since we are currently in the
>>>> sub-optimal position of forcing ~100 ms latency on USB devices. The
>>>> original thread is here --
>>>>
>>
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.html
>>>>
>>>>
>>>> I see two flags that are possibly of consequence here:
>>>> SNDRV_PCM_INFO_BATCH and SNDRV_PCM_INFO_BLOCK_TRANSFER. I'm not sure
>>>> what these mean -- the documentation mentions "double buffering" for
>>>> the batch flag, and just that the block transfer means "block
>>>> transfer". :-)
>>>>
>>>> We've spoken about batch meaning either transfers in period size
>>>> chunks, or some fixed chunk size. It seems that it would make more
>>>> sense for it to mean the former, and block transfer to mean the
>>>> latter.
>>>>
>>>> So I guess the first thing that would be nice to have is a clear
>>>> meaning of these two flags. With this done, we could potentially get
>>>> to the API to report the transfer size from the driver.
>>>
>>>
>>>
>>> Yeah, the meaning of those flags is somewhat fuzzy and may have changed
>>
>> over time as well. Here is my understanding of the flags, might not
>> necessarily be 100% correct.
>>>
>>>
>>> SNDRV_PCM_INFO_BLOCK_TRANSFER means that the data is copied from the
user
>>
>> accessible buffer in blocks of one period. Typically these kinds of
devices
>> have some dedicated audio memory that is not accessible via normal memory
>> access and a DMA is setup to copy data from main memory to the dedicated
>> memory. This DMA transfers the data from the main memory to the dedicated
>> memory in chunks of period size. But otherwise the controller might still
>> be capable of reporting a accurate pointer position down to the
>> sample/frame level.
>>>
>>>
>>> So SNDRV_PCM_INFO_BLOCK_TRANSFER is mainly important for rewind handling
>>
>> and devices with that flag set might need additional headroom since the
>> data up to one period after the pointer position has already been copied
to
>> the dedicated memory and hence can no longer be overwritten.
>>>
>>>
>>> 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.
>> Typically this means a period sized granularity, but there are some other
>> cases as well.
>>>
>>>
>>
>> DSP_CAP_REALTIME bit tells if the device/operating system supports
precise
>> reporting of output pointer position using SNDCTL_DSP_GETxPTR. Precise
>> means that accuracy of the reported playback pointer (time) is around few
>> samples. Without this capability the playback/recording position is
>> reported using precision of one fragment.
>>
>> DSP_CAP_BATCH bit means that the device has some kind of local storage
for
>> recording and/or playback. For this reason the information reported by
>> SNDCTL_DSP_GETxPTR is very inaccurate.
>>
>> Are those alsa cap have the similar meaning of those oss cap ?
>
>
> I would say historically SNDRV_PCM_INFO_BATCH had the same meaning as
DSP_CAP_BATCH, but it has also come to have the inverse meaning to
DSP_CAP_REALTIME. By default applications can assume that the pointer is
accurate down to a few samples, but if SNDRV_PCM_INFO_BATCH is set it is
less accurate and can be everything up to period size precession.
>
> SNDRV_PCM_INFO_BLOCK_TRANSFER is different from all of them though.

 DMA_RESIDUE_GRANULARITY_DESCRIPTOR
DMA_RESIDUE_GRANULARITY_SEGMENT
DMA_RESIDUE_GRANULARITY_BURST

Can this be regard as bad, normal and good accuracy ?

https://bugs.freedesktop.org/show_bug.cgi?id=86262

Although the resolution seem less than period size but the deviation is
quite large , can we still regard this result are accurate up to one period
?

http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-June/024022.html

This is accurate up to one period

Why do we need flag for exactly one period since most of the driver use irq
should increment one period when interrupt occur ?

We only need to know those good accuracy can use timer base and those bad
accuracy need special care

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Lars-Peter Clausen]

On 06/15/2015 03:34 PM, Raymond Yau wrote:
>
>  >>>>
>  >>>>
>  >>>> Hi folks,
>  >>>> I'd like to bring this one up again, since we are currently in the
>  >>>> sub-optimal position of forcing ~100 ms latency on USB devices. The
>  >>>> original thread is here --
>  >>>>
>  >>
> http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.html
>  >>>>
>  >>>>
>  >>>> I see two flags that are possibly of consequence here:
>  >>>> SNDRV_PCM_INFO_BATCH and SNDRV_PCM_INFO_BLOCK_TRANSFER. I'm not sure
>  >>>> what these mean -- the documentation mentions "double buffering" for
>  >>>> the batch flag, and just that the block transfer means "block
>  >>>> transfer". :-)
>  >>>>
>  >>>> We've spoken about batch meaning either transfers in period size
>  >>>> chunks, or some fixed chunk size. It seems that it would make more
>  >>>> sense for it to mean the former, and block transfer to mean the
>  >>>> latter.
>  >>>>
>  >>>> So I guess the first thing that would be nice to have is a clear
>  >>>> meaning of these two flags. With this done, we could potentially get
>  >>>> to the API to report the transfer size from the driver.
>  >>>
>  >>>
>  >>>
>  >>> Yeah, the meaning of those flags is somewhat fuzzy and may have changed
>  >>
>  >> over time as well. Here is my understanding of the flags, might not
>  >> necessarily be 100% correct.
>  >>>
>  >>>
>  >>> SNDRV_PCM_INFO_BLOCK_TRANSFER means that the data is copied from the user
>  >>
>  >> accessible buffer in blocks of one period. Typically these kinds of devices
>  >> have some dedicated audio memory that is not accessible via normal memory
>  >> access and a DMA is setup to copy data from main memory to the dedicated
>  >> memory. This DMA transfers the data from the main memory to the dedicated
>  >> memory in chunks of period size. But otherwise the controller might still
>  >> be capable of reporting a accurate pointer position down to the
>  >> sample/frame level.
>  >>>
>  >>>
>  >>> So SNDRV_PCM_INFO_BLOCK_TRANSFER is mainly important for rewind handling
>  >>
>  >> and devices with that flag set might need additional headroom since the
>  >> data up to one period after the pointer position has already been copied to
>  >> the dedicated memory and hence can no longer be overwritten.
>  >>>
>  >>>
>  >>> 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.
>  >> Typically this means a period sized granularity, but there are some other
>  >> cases as well.
>  >>>
>  >>>
>  >>
>  >> DSP_CAP_REALTIME bit tells if the device/operating system supports precise
>  >> reporting of output pointer position using SNDCTL_DSP_GETxPTR. Precise
>  >> means that accuracy of the reported playback pointer (time) is around few
>  >> samples. Without this capability the playback/recording position is
>  >> reported using precision of one fragment.
>  >>
>  >> DSP_CAP_BATCH bit means that the device has some kind of local storage for
>  >> recording and/or playback. For this reason the information reported by
>  >> SNDCTL_DSP_GETxPTR is very inaccurate.
>  >>
>  >> Are those alsa cap have the similar meaning of those oss cap ?
>  >
>  >
>  > I would say historically SNDRV_PCM_INFO_BATCH had the same meaning as
> DSP_CAP_BATCH, but it has also come to have the inverse meaning to
> DSP_CAP_REALTIME. By default applications can assume that the pointer is
> accurate down to a few samples, but if SNDRV_PCM_INFO_BATCH is set it is
> less accurate and can be everything up to period size precession.
>  >
>  > SNDRV_PCM_INFO_BLOCK_TRANSFER is different from all of them though.
>
> DMA_RESIDUE_GRANULARITY_DESCRIPTOR
> DMA_RESIDUE_GRANULARITY_SEGMENT
> DMA_RESIDUE_GRANULARITY_BURST
>
> Can this be regard as bad, normal and good accuracy ?

DMA_RESIDUE_GRANULARITY_DESCRIPTOR is more like completely and utterly 
useless. It means the driver can only tell whether the descriptor has 
finished or not, in a cyclic transfer the descriptor will never finish so 
the driver will always report the same. Currently we fall back to counting 
the number of period completion callbacks we get in this mode. This is 
slightly prone to race conditions since it is legal to coalesce two 
completion callbacks if a second one is scheduled before the first has run. 
This will only happen with a very high system load, but it can happen. 
Luckily most DMA drivers that are used for audio do support 
DMA_RESIDUE_GRANULARITY_SEGMENT now and there is a deprecation plan, 
including eventually stopping to support them altogether, for drivers that 
only support DMA_RESIDUE_GRANULARITY_DESCRIPTOR.


DMA_RESIDUE_GRANULARITY_SEGMENT means the hardware/driver can report the 
pointer position with a period precession. In this case the BATCH flag will 
be set for the PCM.

DMA_RESIDUE_GRANULARITY_BURST means it can report the position with a 
granularity of a few samples. Typically half the audio FIFO size.

>
> https://bugs.freedesktop.org/show_bug.cgi?id=86262
>
> Although the resolution seem less than period size but the deviation is
> quite large , can we still regard this result are accurate up to one period ?

This looks like a separate issue that's just made visible by the BATCH flag 
patch with that particular hardware.

>
> http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-June/024022.html
>
> This is accurate up to one period
>
> Why do we need flag for exactly one period since most of the driver use irq
> should increment one period when interrupt occur ?
>
> We only need to know those good accuracy can use timer base and those bad
> accuracy need special care

Yes, and that's what the BATCH flag tells us.

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>> DMA_RESIDUE_GRANULARITY_DESCRIPTOR
>> DMA_RESIDUE_GRANULARITY_SEGMENT
>> DMA_RESIDUE_GRANULARITY_BURST
>>
>> Can this be regard as bad, normal and good accuracy ?
>
>
> DMA_RESIDUE_GRANULARITY_DESCRIPTOR is more like completely and utterly
useless. It means the driver can only tell whether the descriptor has
finished or not, in a cyclic transfer the descriptor will never finish so
the driver will always report the same. Currently we fall back to counting
the number of period completion callbacks we get in this mode. This is
slightly prone to race conditions since it is legal to coalesce two
completion callbacks if a second one is scheduled before the first has run.
This will only happen with a very high system load, but it can happen.
Luckily most DMA drivers that are used for audio do support
DMA_RESIDUE_GRANULARITY_SEGMENT now and there is a deprecation plan,
including eventually stopping to support them altogether, for drivers that
only support DMA_RESIDUE_GRANULARITY_DESCRIPTOR.
>
>
> DMA_RESIDUE_GRANULARITY_SEGMENT means the hardware/driver can report the
pointer position with a period precession. In this case the BATCH flag will
be set for the PCM.
>
> DMA_RESIDUE_GRANULARITY_BURST means it can report the position with a
granularity of a few samples. Typically half the audio FIFO size.
>
>

Residue is updated after each transferred
*  burst. This is typically only supported if the hardware has a progress
*  register of some sort (E.g. a register with the current read/write
address
*  or a register with the amount of bursts/beats/bytes that have been
*  transferred or still need to be transferred).

The pointer callback of both snd-hda-intel and snd-oxygen are reading from
hardware register

Do this mezn that only those driver which pointer callback read from
hardware register are suitable for timer schedluing ?

Do you need additional hardware specific feature (e.g. can disable period
interrupt ) ?

>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=86262
>>
>> Although the resolution seem less than period size but the deviation is
>> quite large , can we still regard this result are accurate up to one
period ?
>
>
> This looks like a separate issue that's just made visible by the BATCH
flag patch with that particular hardware.

https://bugs.freedesktop.org/show_bug.cgi?id=86262#c19

The hw_ptr of those two usb audio devices seem increment in 5 to 6ms which
is quite different from

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/usb?id=976b6c064a957445eb0573b270f2d0282630e9b9

For example, testing shows that a high-speed device can handle 32
frames/period and 3 periods/buffer at 48 KHz, whereas the current driver
starts to get glitchy at 64 frames/period and 2 periods/buffer.

Do the result mean that only high speed device support 1.5ms latency while
the other usb audio devices may support 15 to 18 ms ?

>
>>
>>
http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-June/024022.html
>>
>> This is accurate up to one period
>>
>> Why do we need flag for exactly one period since most of the driver use
irq
>> should increment one period when interrupt occur ?
>>
>> We only need to know those good accuracy can use timer base and those bad
>> accuracy need special care
>
>
> Yes, and that's what the BATCH flag tells us.

For those sound cards support low latency, the application must use smaller
petiod size which match the requestef latency. Most drivers only support
fixed latency. Only those sound card with good accuracy can adjust latency
without changing period size

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>>> Hi folks,
>>> I'd like to bring this one up again, since we are currently in the
>>> sub-optimal position of forcing ~100 ms latency on USB devices. The
>>> original thread is here --
>>>
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-December/069666.html
>>
>>
>> While we sort this out, though, is there an upper bound on the USB
>> transfer size (that we could then use a rewind safety margin)? We
>> might be able to use this as a workaround till this can be fixed
>> properly.
>
>
> Hello Arun,
>
> thanks for bringing up the issue again. However, I think that the "~100
ms latency on batch cards" problem can and should also be solved from the
other end, independently from the USB special case. Namely, I think that
the default buffer and period sizes that PulseAudio selects are way too
conservative. The power-saving argument was used in the past as a
justification, and I am calling for a reevaluation. Here is why.
>
> 1. Android's AudioFlinger uses 2 periods, 5 ms each. It is a mobile OS,
and the developers think it is good enough.
>
> 2. I have measured the battery life time of my SandyBridge-based laptop
and found that, with pure ALSA on the hw:0 device, a similar low-latency
setup loses less than 5% of the battery life (935 seconds were lost out of
25742). With PulseAudio, the difference is worse, but let's treat this as a
missed optimization in PulseAudio.

http://www.intel.com/content/www/us/en/chipsets/high-definition-audio-energy-efficient-audio-buffering.html

Do your hda controller support EEaudio Mechanism ?

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Alexander E. Patrakov]

On 17.06.2015 08:04, Raymond Yau wrote:
>
> http://www.intel.com/content/www/us/en/chipsets/high-definition-audio-energy-efficient-audio-buffering.html
>
> Do your hda controller support EEaudio Mechanism ?
>

I don't know.

-- 
Alexander E. Patrakov

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Lars-Peter Clausen]

On 06/16/2015 04:33 AM, Raymond Yau wrote:
>
>  >> DMA_RESIDUE_GRANULARITY_DESCRIPTOR
>  >> DMA_RESIDUE_GRANULARITY_SEGMENT
>  >> DMA_RESIDUE_GRANULARITY_BURST
>  >>
>  >> Can this be regard as bad, normal and good accuracy ?
>  >
>  >
>  > DMA_RESIDUE_GRANULARITY_DESCRIPTOR is more like completely and utterly
> useless. It means the driver can only tell whether the descriptor has
> finished or not, in a cyclic transfer the descriptor will never finish so
> the driver will always report the same. Currently we fall back to counting
> the number of period completion callbacks we get in this mode. This is
> slightly prone to race conditions since it is legal to coalesce two
> completion callbacks if a second one is scheduled before the first has run.
> This will only happen with a very high system load, but it can happen.
> Luckily most DMA drivers that are used for audio do support
> DMA_RESIDUE_GRANULARITY_SEGMENT now and there is a deprecation plan,
> including eventually stopping to support them altogether, for drivers that
> only support DMA_RESIDUE_GRANULARITY_DESCRIPTOR.
>  >
>  >
>  > DMA_RESIDUE_GRANULARITY_SEGMENT means the hardware/driver can report the
> pointer position with a period precession. In this case the BATCH flag will
> be set for the PCM.
>  >
>  > DMA_RESIDUE_GRANULARITY_BURST means it can report the position with a
> granularity of a few samples. Typically half the audio FIFO size.
>  >
>  >
>
> Residue is updated after each transferred
> *  burst. This is typically only supported if the hardware has a progress
> *  register of some sort (E.g. a register with the current read/write address
> *  or a register with the amount of bursts/beats/bytes that have been
> *  transferred or still need to be transferred).
>
> The pointer callback of both snd-hda-intel and snd-oxygen are reading from
> hardware register
>
> Do this mezn that only those driver which pointer callback read from
> hardware register are suitable for timer schedluing ?

Yes, more or less, but not exclusively. The pointer callback needs to a have 
a low enough precession for timer based scheduling to work. Where the 
threshold is where it starts and stops to work is a bit hard to say. Period 
based resolution is not good enough, a few samples based resolution is very 
good. USB seems to be somewhere in the middle between those two, the 
resolution is better then a full period, but more than just a few samples. 
But it seems to be good enough for the timer based scheduling algorithm to 
work. It still gets disabled for USB though since the USB driver stets the 
BATCH flag.

The main issue is that there is currently no method for a driver to 
advertise the exact pointer granularity to userspace applications. There is 
either BATCH flag not set which means very good accuracy or BATCH flag set 
which means very bad accuracy. USB which does not have a very good accuracy, 
but still a reasonably good accuracy, is somewhere in the middle between 
those two extremes.

>
> Do you need additional hardware specific feature (e.g. can disable period
> interrupt ) ?

No. Disabling the period interrupt is a feature that can be used to reduce 
power consumption and is optional.

>
>  >>
>  >> https://bugs.freedesktop.org/show_bug.cgi?id=86262
>  >>
>  >> Although the resolution seem less than period size but the deviation is
>  >> quite large , can we still regard this result are accurate up to one
> period ?
>  >
>  >
>  > This looks like a separate issue that's just made visible by the BATCH
> flag patch with that particular hardware.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=86262#c19
>
> The hw_ptr of those two usb audio devices seem increment in 5 to 6ms which
> is quite different from
>
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/usb?id=976b6c064a957445eb0573b270f2d0282630e9b9
>
> For example, testing shows that a high-speed device can handle 32
> frames/period and 3 periods/buffer at 48 KHz, whereas the current driver
> starts to get glitchy at 64 frames/period and 2 periods/buffer.
>
> Do the result mean that only high speed device support 1.5ms latency while
> the other usb audio devices may support 15 to 18 ms ?
>
>  >
>  >>
>  >>
> http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-June/024022.html
>  >>
>  >> This is accurate up to one period
>  >>
>  >> Why do we need flag for exactly one period since most of the driver use irq
>  >> should increment one period when interrupt occur ?
>  >>
>  >> We only need to know those good accuracy can use timer base and those bad
>  >> accuracy need special care
>  >
>  >
>  > Yes, and that's what the BATCH flag tells us.
>
> For those sound cards support low latency, the application must use smaller
> petiod size which match the requestef latency. Most drivers only support
> fixed latency. Only those sound card with good accuracy can adjust latency
> without changing period size

Yes, without a good precession pointer the lower bound for the latency will 
be determined by the period size. A smaller period size means less latency.

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Takashi Iwai]

At Wed, 17 Jun 2015 10:27:08 +0200,
Lars-Peter Clausen wrote:
> 
> On 06/16/2015 04:33 AM, Raymond Yau wrote:
> >
> >  >> DMA_RESIDUE_GRANULARITY_DESCRIPTOR
> >  >> DMA_RESIDUE_GRANULARITY_SEGMENT
> >  >> DMA_RESIDUE_GRANULARITY_BURST
> >  >>
> >  >> Can this be regard as bad, normal and good accuracy ?
> >  >
> >  >
> >  > DMA_RESIDUE_GRANULARITY_DESCRIPTOR is more like completely and utterly
> > useless. It means the driver can only tell whether the descriptor has
> > finished or not, in a cyclic transfer the descriptor will never finish so
> > the driver will always report the same. Currently we fall back to counting
> > the number of period completion callbacks we get in this mode. This is
> > slightly prone to race conditions since it is legal to coalesce two
> > completion callbacks if a second one is scheduled before the first has run.
> > This will only happen with a very high system load, but it can happen.
> > Luckily most DMA drivers that are used for audio do support
> > DMA_RESIDUE_GRANULARITY_SEGMENT now and there is a deprecation plan,
> > including eventually stopping to support them altogether, for drivers that
> > only support DMA_RESIDUE_GRANULARITY_DESCRIPTOR.
> >  >
> >  >
> >  > DMA_RESIDUE_GRANULARITY_SEGMENT means the hardware/driver can report the
> > pointer position with a period precession. In this case the BATCH flag will
> > be set for the PCM.
> >  >
> >  > DMA_RESIDUE_GRANULARITY_BURST means it can report the position with a
> > granularity of a few samples. Typically half the audio FIFO size.
> >  >
> >  >
> >
> > Residue is updated after each transferred
> > *  burst. This is typically only supported if the hardware has a progress
> > *  register of some sort (E.g. a register with the current read/write address
> > *  or a register with the amount of bursts/beats/bytes that have been
> > *  transferred or still need to be transferred).
> >
> > The pointer callback of both snd-hda-intel and snd-oxygen are reading from
> > hardware register
> >
> > Do this mezn that only those driver which pointer callback read from
> > hardware register are suitable for timer schedluing ?
> 
> Yes, more or less, but not exclusively. The pointer callback needs to a have 
> a low enough precession for timer based scheduling to work. Where the 
> threshold is where it starts and stops to work is a bit hard to say. Period 
> based resolution is not good enough, a few samples based resolution is very 
> good. USB seems to be somewhere in the middle between those two, the 
> resolution is better then a full period, but more than just a few samples. 
> But it seems to be good enough for the timer based scheduling algorithm to 
> work. It still gets disabled for USB though since the USB driver stets the 
> BATCH flag.
> 
> The main issue is that there is currently no method for a driver to 
> advertise the exact pointer granularity to userspace applications. There is 
> either BATCH flag not set which means very good accuracy or BATCH flag set 
> which means very bad accuracy. USB which does not have a very good accuracy, 
> but still a reasonably good accuracy, is somewhere in the middle between 
> those two extremes.

Well, USB-audio has another problem.  USB-audio uses the intermediate
audio ring buffer, and the samples are copied to each URB buffer.  At
each packet complete, the driver copies the rest of sample chunk
again, and advances the hwptr when the packets.  So, the hwptr of
USB-audio is in advance of the actual sample position.  But we provide
the runtime delay information for user-space to correct to the more
accurate sample position.  So far, so good.

A missing piece in this picture is, however, the position of the
not-yet-queued samples in ring buffer.  Basically you can rewrite /
rewind the sample at most this point, but not farther -- such
in-flight samples can't be modified any longer.  This can be seen a
kind of hardware fifo with a pretty big and non-continuously variable
size during operation.

In that sense, get_fifo() looks like a candidate for giving such
information, indeed.  But reviving the old (and rather bad working)
API appears dangerous to me.  I'd prefer creating a new API function
instead, if any.

BTW, because of its design like above, a large (or no) period size
doesn't help for saving power at all with USB-audio.  This should be
considered before the further discussion...


Takashi

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[David Henningsson]

On 2015-06-17 11:19, Takashi Iwai wrote:
> Well, USB-audio has another problem.  USB-audio uses the intermediate
> audio ring buffer, and the samples are copied to each URB buffer.  At
> each packet complete, the driver copies the rest of sample chunk
> again, and advances the hwptr when the packets.  So, the hwptr of
> USB-audio is in advance of the actual sample position.  But we provide
> the runtime delay information for user-space to correct to the more
> accurate sample position.  So far, so good.
>
> A missing piece in this picture is, however, the position of the
> not-yet-queued samples in ring buffer.  Basically you can rewrite /
> rewind the sample at most this point, but not farther -- such
> in-flight samples can't be modified any longer.  This can be seen a
> kind of hardware fifo with a pretty big and non-continuously variable
> size during operation.
>
> In that sense, get_fifo() looks like a candidate for giving such
> information, indeed.  But reviving the old (and rather bad working)
> API appears dangerous to me.  I'd prefer creating a new API function
> instead, if any.
>
> BTW, because of its design like above, a large (or no) period size
> doesn't help for saving power at all with USB-audio.  This should be
> considered before the further discussion...

Hmm...I was trying to understand this power save argument. I tried to 
figure out a "typical" URB size by just plugging my headset in, and I 
saw wMaxPacketSize being 96 and/or 192 bytes.
Then, MAX_PACKS is set to either 6 (or 48 for USB 2.0 devices, but this 
is just a headset).

Can this be correct? Does it mean that we are getting interrupts every 
192 * 6 bytes (i e, every 6 ms for a 48kHz/stereo/16bit stream)?


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Alexander E. Patrakov]

[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]

On 17.06.2015 20:09, David Henningsson wrote:
>
>
> On 2015-06-17 11:19, Takashi Iwai wrote:
>> Well, USB-audio has another problem.  USB-audio uses the intermediate
>> audio ring buffer, and the samples are copied to each URB buffer.  At
>> each packet complete, the driver copies the rest of sample chunk
>> again, and advances the hwptr when the packets.  So, the hwptr of
>> USB-audio is in advance of the actual sample position.  But we provide
>> the runtime delay information for user-space to correct to the more
>> accurate sample position.  So far, so good.
>>
>> A missing piece in this picture is, however, the position of the
>> not-yet-queued samples in ring buffer.  Basically you can rewrite /
>> rewind the sample at most this point, but not farther -- such
>> in-flight samples can't be modified any longer.  This can be seen a
>> kind of hardware fifo with a pretty big and non-continuously variable
>> size during operation.
>>
>> In that sense, get_fifo() looks like a candidate for giving such
>> information, indeed.  But reviving the old (and rather bad working)
>> API appears dangerous to me.  I'd prefer creating a new API function
>> instead, if any.
>>
>> BTW, because of its design like above, a large (or no) period size
>> doesn't help for saving power at all with USB-audio.  This should be
>> considered before the further discussion...
>
> Hmm...I was trying to understand this power save argument. I tried to
> figure out a "typical" URB size by just plugging my headset in, and I
> saw wMaxPacketSize being 96 and/or 192 bytes.
> Then, MAX_PACKS is set to either 6 (or 48 for USB 2.0 devices, but this
> is just a headset).
>
> Can this be correct? Does it mean that we are getting interrupts every
> 192 * 6 bytes (i e, every 6 ms for a 48kHz/stereo/16bit stream)?

At least that's how often the position gets updated in the worst case. I 
have attached a report for a Logitech USB headset and a test program 
where you can modify the buffer and period sizes. A line is logged every 
time snd_pcm_avail() returns a different value.

-- 
Alexander E. Patrakov

[-- Attachment #2: usb_sound_timings.txt --]
[-- Type: text/plain, Size: 22411 bytes --]

======= testing hw:2 =======
min_period_size: 48 frames, dir: 0
FIFO size is 0
Hardware PCM card 2 'C-Media USB Headphone Set' 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
  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: 6 usec
Available: 288, loop iteration: 2621, diff: 2621, timestamp diff: 5560 usec
Available: 528, loop iteration: 4934, diff: 2313, timestamp diff: 5985 usec
Available: 768, loop iteration: 6804, diff: 1870, timestamp diff: 6000 usec
Available: 1056, loop iteration: 8810, diff: 2006, timestamp diff: 5998 usec
Available: 1296, loop iteration: 10533, diff: 1723, timestamp diff: 5011 usec
Available: 1536, loop iteration: 12238, diff: 1705, timestamp diff: 4997 usec
Available: 1824, loop iteration: 14428, diff: 2190, timestamp diff: 6014 usec
Available: 2064, loop iteration: 16434, diff: 2006, timestamp diff: 4986 usec
Available: 2304, loop iteration: 18209, diff: 1775, timestamp diff: 4989 usec
Available: 2592, loop iteration: 20846, diff: 2637, timestamp diff: 5995 usec
Available: 2832, loop iteration: 23188, diff: 2342, timestamp diff: 5004 usec
Available: 3072, loop iteration: 25568, diff: 2380, timestamp diff: 4998 usec
Available: 3360, loop iteration: 28495, diff: 2927, timestamp diff: 6002 usec
Available: 3600, loop iteration: 30172, diff: 1677, timestamp diff: 5000 usec
Available: 3840, loop iteration: 32005, diff: 1833, timestamp diff: 4996 usec
======= testing hw:2 =======
min_period_size: 48 frames, dir: 0
FIFO size is 0
Hardware PCM card 2 'C-Media USB Headphone Set' 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  : 512
  period_size  : 128
  period_time  : 2666
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 128
  period_event : 0
  start_threshold  : 128
  stop_threshold   : 512
  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: 6 usec
Available: 144, loop iteration: 2384, diff: 2384, timestamp diff: 2621 usec
Available: 288, loop iteration: 4286, diff: 1902, timestamp diff: 2996 usec
Available: 384, loop iteration: 6134, diff: 1848, timestamp diff: 3063 usec
======= testing hw:2 =======
min_period_size: 48 frames, dir: 0
FIFO size is 0
Hardware PCM card 2 'C-Media USB Headphone Set' 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  : 512
  period_size  : 128
  period_time  : 2666
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 128
  period_event : 0
  start_threshold  : 128
  stop_threshold   : 512
  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: 5 usec
Available: 144, loop iteration: 2963, diff: 2963, timestamp diff: 3114 usec
Available: 288, loop iteration: 4528, diff: 1565, timestamp diff: 2993 usec
Available: 384, loop iteration: 4943, diff: 415, timestamp diff: 3807 usec
======= testing hw:2 =======
min_period_size: 48 frames, dir: 0
FIFO size is 0
Hardware PCM card 2 'C-Media USB Headphone Set' 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  : 128
  period_time  : 2666
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 128
  period_event : 0
  start_threshold  : 128
  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: 6 usec
Available: 144, loop iteration: 2907, diff: 2907, timestamp diff: 3099 usec
Available: 288, loop iteration: 4192, diff: 1285, timestamp diff: 4498 usec
Available: 384, loop iteration: 4957, diff: 765, timestamp diff: 1496 usec
Available: 528, loop iteration: 5447, diff: 490, timestamp diff: 3017 usec
Available: 672, loop iteration: 6718, diff: 1271, timestamp diff: 5295 usec
Available: 768, loop iteration: 7035, diff: 317, timestamp diff: 701 usec
Available: 912, loop iteration: 8346, diff: 1311, timestamp diff: 4201 usec
Available: 1056, loop iteration: 9278, diff: 932, timestamp diff: 1788 usec
Available: 1152, loop iteration: 9948, diff: 670, timestamp diff: 1996 usec
Available: 1296, loop iteration: 11591, diff: 1643, timestamp diff: 3007 usec
Available: 1440, loop iteration: 12760, diff: 1169, timestamp diff: 2995 usec
Available: 1536, loop iteration: 13759, diff: 999, timestamp diff: 2010 usec
Available: 1680, loop iteration: 15285, diff: 1526, timestamp diff: 2990 usec
Available: 1824, loop iteration: 16887, diff: 1602, timestamp diff: 2998 usec
Available: 1920, loop iteration: 17762, diff: 875, timestamp diff: 2001 usec
Available: 2064, loop iteration: 19287, diff: 1525, timestamp diff: 2996 usec
Available: 2208, loop iteration: 20872, diff: 1585, timestamp diff: 2998 usec
Available: 2304, loop iteration: 21980, diff: 1108, timestamp diff: 2003 usec
Available: 2448, loop iteration: 23677, diff: 1697, timestamp diff: 3014 usec
Available: 2592, loop iteration: 25332, diff: 1655, timestamp diff: 2988 usec
Available: 2688, loop iteration: 26443, diff: 1111, timestamp diff: 1999 usec
Available: 2832, loop iteration: 28060, diff: 1617, timestamp diff: 3007 usec
Available: 2976, loop iteration: 29702, diff: 1642, timestamp diff: 2997 usec
Available: 3072, loop iteration: 30748, diff: 1046, timestamp diff: 1989 usec
Available: 3216, loop iteration: 32351, diff: 1603, timestamp diff: 3006 usec
Available: 3360, loop iteration: 33923, diff: 1572, timestamp diff: 3013 usec
Available: 3456, loop iteration: 34982, diff: 1059, timestamp diff: 1990 usec
Available: 3600, loop iteration: 36595, diff: 1613, timestamp diff: 2999 usec
Available: 3744, loop iteration: 38126, diff: 1531, timestamp diff: 3007 usec
Available: 3840, loop iteration: 39131, diff: 1005, timestamp diff: 1987 usec
Available: 3984, loop iteration: 40743, diff: 1612, timestamp diff: 3004 usec
======= testing hw:2 =======
min_period_size: 48 frames, dir: 0
FIFO size is 0
Hardware PCM card 2 'C-Media USB Headphone Set' 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  : 32768
  period_size  : 8192
  period_time  : 170666
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 8192
  period_event : 0
  start_threshold  : 8192
  stop_threshold   : 32768
  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: 6 usec
Available: 288, loop iteration: 5758, diff: 5758, timestamp diff: 6060 usec
Available: 576, loop iteration: 8994, diff: 3236, timestamp diff: 5981 usec
Available: 864, loop iteration: 9998, diff: 1004, timestamp diff: 10924 usec
Available: 1152, loop iteration: 10591, diff: 593, timestamp diff: 1078 usec
Available: 1440, loop iteration: 13865, diff: 3274, timestamp diff: 6010 usec
Available: 1728, loop iteration: 16758, diff: 2893, timestamp diff: 5989 usec
Available: 2016, loop iteration: 19899, diff: 3141, timestamp diff: 6001 usec
Available: 2304, loop iteration: 23141, diff: 3242, timestamp diff: 6009 usec
Available: 2592, loop iteration: 26416, diff: 3275, timestamp diff: 5990 usec
Available: 2832, loop iteration: 29733, diff: 3317, timestamp diff: 6001 usec
Available: 3120, loop iteration: 32973, diff: 3240, timestamp diff: 6008 usec
Available: 3408, loop iteration: 36215, diff: 3242, timestamp diff: 5986 usec
Available: 3696, loop iteration: 39013, diff: 2798, timestamp diff: 5002 usec
Available: 3984, loop iteration: 42252, diff: 3239, timestamp diff: 6007 usec
Available: 4272, loop iteration: 45450, diff: 3198, timestamp diff: 5992 usec
Available: 4560, loop iteration: 48762, diff: 3312, timestamp diff: 6000 usec
Available: 4848, loop iteration: 52013, diff: 3251, timestamp diff: 6002 usec
Available: 5136, loop iteration: 55228, diff: 3215, timestamp diff: 5994 usec
Available: 5424, loop iteration: 58508, diff: 3280, timestamp diff: 6003 usec
Available: 5664, loop iteration: 61803, diff: 3295, timestamp diff: 6001 usec
Available: 5952, loop iteration: 65035, diff: 3232, timestamp diff: 5999 usec
Available: 6240, loop iteration: 68285, diff: 3250, timestamp diff: 5997 usec
Available: 6528, loop iteration: 71028, diff: 2743, timestamp diff: 5001 usec
Available: 6816, loop iteration: 74260, diff: 3232, timestamp diff: 6001 usec
Available: 7104, loop iteration: 77483, diff: 3223, timestamp diff: 5998 usec
Available: 7392, loop iteration: 80763, diff: 3280, timestamp diff: 6002 usec
Available: 7680, loop iteration: 83994, diff: 3231, timestamp diff: 5998 usec
Available: 7968, loop iteration: 87264, diff: 3270, timestamp diff: 6000 usec
Available: 8208, loop iteration: 90594, diff: 3330, timestamp diff: 6010 usec
Available: 8496, loop iteration: 93736, diff: 3142, timestamp diff: 5991 usec
Available: 8784, loop iteration: 96978, diff: 3242, timestamp diff: 5999 usec
Available: 9072, loop iteration: 99722, diff: 2744, timestamp diff: 5213 usec
Available: 9360, loop iteration: 102870, diff: 3148, timestamp diff: 5784 usec
Available: 9648, loop iteration: 106131, diff: 3261, timestamp diff: 5999 usec
Available: 9936, loop iteration: 109396, diff: 3265, timestamp diff: 6008 usec
Available: 10176, loop iteration: 112670, diff: 3274, timestamp diff: 5991 usec
Available: 10464, loop iteration: 115949, diff: 3279, timestamp diff: 6003 usec
Available: 10752, loop iteration: 119133, diff: 3184, timestamp diff: 6000 usec
Available: 11040, loop iteration: 121861, diff: 2728, timestamp diff: 5007 usec
Available: 11328, loop iteration: 125087, diff: 3226, timestamp diff: 5991 usec
Available: 11616, loop iteration: 128297, diff: 3210, timestamp diff: 6001 usec
Available: 11904, loop iteration: 131508, diff: 3211, timestamp diff: 6007 usec
Available: 12192, loop iteration: 134751, diff: 3243, timestamp diff: 5992 usec
Available: 12480, loop iteration: 138020, diff: 3269, timestamp diff: 5997 usec
Available: 12720, loop iteration: 141905, diff: 3885, timestamp diff: 6004 usec
Available: 13008, loop iteration: 145912, diff: 4007, timestamp diff: 5995 usec
Available: 13296, loop iteration: 149204, diff: 3292, timestamp diff: 6005 usec
Available: 13584, loop iteration: 151936, diff: 2732, timestamp diff: 5010 usec
Available: 13872, loop iteration: 155234, diff: 3298, timestamp diff: 5984 usec
Available: 14160, loop iteration: 158505, diff: 3271, timestamp diff: 6003 usec
Available: 14448, loop iteration: 161738, diff: 3233, timestamp diff: 6007 usec
Available: 14736, loop iteration: 164654, diff: 2916, timestamp diff: 5994 usec
Available: 15024, loop iteration: 167883, diff: 3229, timestamp diff: 5997 usec
Available: 15312, loop iteration: 171085, diff: 3202, timestamp diff: 6013 usec
Available: 15552, loop iteration: 174292, diff: 3207, timestamp diff: 5985 usec
Available: 15840, loop iteration: 177599, diff: 3307, timestamp diff: 6000 usec
Available: 16128, loop iteration: 180910, diff: 3311, timestamp diff: 6011 usec
Available: 16416, loop iteration: 183632, diff: 2722, timestamp diff: 4986 usec
Available: 16704, loop iteration: 186775, diff: 3143, timestamp diff: 6002 usec
Available: 16992, loop iteration: 190041, diff: 3266, timestamp diff: 6010 usec
Available: 17280, loop iteration: 193280, diff: 3239, timestamp diff: 5988 usec
Available: 17520, loop iteration: 196472, diff: 3192, timestamp diff: 6001 usec
Available: 17808, loop iteration: 199722, diff: 3250, timestamp diff: 5998 usec
Available: 18096, loop iteration: 202932, diff: 3210, timestamp diff: 6001 usec
Available: 18384, loop iteration: 205659, diff: 2727, timestamp diff: 5003 usec
Available: 18672, loop iteration: 208904, diff: 3245, timestamp diff: 5998 usec
Available: 18960, loop iteration: 212209, diff: 3305, timestamp diff: 5999 usec
Available: 19248, loop iteration: 215563, diff: 3354, timestamp diff: 5999 usec
Available: 19536, loop iteration: 218857, diff: 3294, timestamp diff: 6002 usec
Available: 19824, loop iteration: 222209, diff: 3352, timestamp diff: 5997 usec
Available: 20064, loop iteration: 225492, diff: 3283, timestamp diff: 6003 usec
Available: 20352, loop iteration: 228637, diff: 3145, timestamp diff: 5999 usec
Available: 20640, loop iteration: 231919, diff: 3282, timestamp diff: 5998 usec
Available: 20928, loop iteration: 234640, diff: 2721, timestamp diff: 5000 usec
Available: 21216, loop iteration: 237912, diff: 3272, timestamp diff: 6001 usec
Available: 21504, loop iteration: 241208, diff: 3296, timestamp diff: 5996 usec
Available: 21792, loop iteration: 244431, diff: 3223, timestamp diff: 5997 usec
Available: 22080, loop iteration: 247673, diff: 3242, timestamp diff: 6009 usec
Available: 22368, loop iteration: 251092, diff: 3419, timestamp diff: 5997 usec
Available: 22656, loop iteration: 254376, diff: 3284, timestamp diff: 5995 usec
Available: 22896, loop iteration: 257490, diff: 3114, timestamp diff: 6007 usec
Available: 23184, loop iteration: 260712, diff: 3222, timestamp diff: 5997 usec
Available: 23472, loop iteration: 263679, diff: 2967, timestamp diff: 6004 usec
Available: 23760, loop iteration: 266440, diff: 2761, timestamp diff: 4990 usec
Available: 24048, loop iteration: 269745, diff: 3305, timestamp diff: 6001 usec
Available: 24336, loop iteration: 273006, diff: 3261, timestamp diff: 6002 usec
Available: 24576, loop iteration: 276372, diff: 3366, timestamp diff: 5994 usec
Available: 24864, loop iteration: 279501, diff: 3129, timestamp diff: 6011 usec
Available: 25152, loop iteration: 282796, diff: 3295, timestamp diff: 5990 usec
Available: 25440, loop iteration: 285381, diff: 2585, timestamp diff: 5000 usec
Available: 25728, loop iteration: 288446, diff: 3065, timestamp diff: 6002 usec
Available: 26016, loop iteration: 291653, diff: 3207, timestamp diff: 6000 usec
Available: 26304, loop iteration: 294848, diff: 3195, timestamp diff: 5996 usec
Available: 26592, loop iteration: 297995, diff: 3147, timestamp diff: 6014 usec
Available: 26880, loop iteration: 301231, diff: 3236, timestamp diff: 5998 usec
Available: 27168, loop iteration: 304342, diff: 3111, timestamp diff: 5988 usec
Available: 27408, loop iteration: 307349, diff: 3007, timestamp diff: 6007 usec
Available: 27696, loop iteration: 310425, diff: 3076, timestamp diff: 5994 usec
Available: 27984, loop iteration: 313506, diff: 3081, timestamp diff: 5998 usec
Available: 28272, loop iteration: 316100, diff: 2594, timestamp diff: 5011 usec
Available: 28560, loop iteration: 319363, diff: 3263, timestamp diff: 5988 usec
Available: 28848, loop iteration: 322609, diff: 3246, timestamp diff: 6004 usec
Available: 29136, loop iteration: 325623, diff: 3014, timestamp diff: 5995 usec
Available: 29424, loop iteration: 328627, diff: 3004, timestamp diff: 6006 usec
Available: 29712, loop iteration: 331894, diff: 3267, timestamp diff: 5997 usec
Available: 30000, loop iteration: 334955, diff: 3061, timestamp diff: 5999 usec
Available: 30240, loop iteration: 337880, diff: 2925, timestamp diff: 5998 usec
Available: 30528, loop iteration: 341150, diff: 3270, timestamp diff: 6002 usec
Available: 30816, loop iteration: 344292, diff: 3142, timestamp diff: 5996 usec
Available: 31104, loop iteration: 346737, diff: 2445, timestamp diff: 5002 usec
Available: 31392, loop iteration: 349724, diff: 2987, timestamp diff: 6011 usec
Available: 31680, loop iteration: 352886, diff: 3162, timestamp diff: 5991 usec
Available: 31968, loop iteration: 355931, diff: 3045, timestamp diff: 5995 usec
Available: 32256, loop iteration: 359009, diff: 3078, timestamp diff: 6001 usec
Available: 32544, loop iteration: 362272, diff: 3263, timestamp diff: 6009 usec
======= testing hw:2 =======
min_period_size: 48 frames, dir: 0
FIFO size is 0
Hardware PCM card 2 'C-Media USB Headphone Set' 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  : 64
  period_time  : 1333
  tstamp_mode  : NONE
  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: 6 usec
Available: 96, loop iteration: 1671, diff: 1671, timestamp diff: 1727 usec
Available: 144, loop iteration: 2588, diff: 917, timestamp diff: 3541 usec
Available: 192, loop iteration: 2779, diff: 191, timestamp diff: 458 usec
Available: 288, loop iteration: 3828, diff: 1049, timestamp diff: 1994 usec
Available: 336, loop iteration: 4222, diff: 394, timestamp diff: 3783 usec
Available: 384, loop iteration: 4316, diff: 94, timestamp diff: 231 usec
Available: 480, loop iteration: 5226, diff: 910, timestamp diff: 2760 usec
Available: 528, loop iteration: 5863, diff: 637, timestamp diff: 1226 usec
Available: 672, loop iteration: 6775, diff: 912, timestamp diff: 4773 usec
Available: 720, loop iteration: 6894, diff: 119, timestamp diff: 225 usec
Available: 768, loop iteration: 7443, diff: 549, timestamp diff: 991 usec
Available: 864, loop iteration: 8360, diff: 917, timestamp diff: 2109 usec
Available: 912, loop iteration: 8840, diff: 480, timestamp diff: 892 usec
Available: 960, loop iteration: 9398, diff: 558, timestamp diff: 1000 usec
Available: 1056, loop iteration: 10456, diff: 1058, timestamp diff: 2004 usec
Available: 1104, loop iteration: 10986, diff: 530, timestamp diff: 996 usec
Available: 1152, loop iteration: 11505, diff: 519, timestamp diff: 1006 usec
Available: 1248, loop iteration: 12595, diff: 1090, timestamp diff: 1998 usec
Available: 1296, loop iteration: 13082, diff: 487, timestamp diff: 995 usec
Available: 1344, loop iteration: 13574, diff: 492, timestamp diff: 1006 usec
Available: 1440, loop iteration: 14647, diff: 1073, timestamp diff: 1999 usec
Available: 1488, loop iteration: 15160, diff: 513, timestamp diff: 995 usec
Available: 1536, loop iteration: 15689, diff: 529, timestamp diff: 1005 usec
Available: 1632, loop iteration: 16750, diff: 1061, timestamp diff: 1996 usec
Available: 1680, loop iteration: 17284, diff: 534, timestamp diff: 997 usec
Available: 1728, loop iteration: 17817, diff: 533, timestamp diff: 1001 usec
Available: 1824, loop iteration: 18876, diff: 1059, timestamp diff: 2013 usec
Available: 1872, loop iteration: 19381, diff: 505, timestamp diff: 987 usec
Available: 1920, loop iteration: 19905, diff: 524, timestamp diff: 999 usec
Available: 2016, loop iteration: 20952, diff: 1047, timestamp diff: 2005 usec
Available: 2064, loop iteration: 21453, diff: 501, timestamp diff: 996 usec
Available: 2112, loop iteration: 21964, diff: 511, timestamp diff: 1000 usec
Available: 2208, loop iteration: 22971, diff: 1007, timestamp diff: 2011 usec
Available: 2256, loop iteration: 23477, diff: 506, timestamp diff: 990 usec
Available: 2304, loop iteration: 24023, diff: 546, timestamp diff: 999 usec
Available: 2400, loop iteration: 25135, diff: 1112, timestamp diff: 2007 usec
Available: 2448, loop iteration: 25659, diff: 524, timestamp diff: 1000 usec
Available: 2496, loop iteration: 26211, diff: 552, timestamp diff: 992 usec
Available: 2592, loop iteration: 27260, diff: 1049, timestamp diff: 2003 usec
Available: 2640, loop iteration: 27783, diff: 523, timestamp diff: 998 usec
Available: 2688, loop iteration: 28326, diff: 543, timestamp diff: 1006 usec
Available: 2784, loop iteration: 29408, diff: 1082, timestamp diff: 1998 usec
Available: 2832, loop iteration: 29924, diff: 516, timestamp diff: 994 usec
Available: 2880, loop iteration: 30431, diff: 507, timestamp diff: 1008 usec
Available: 2976, loop iteration: 31507, diff: 1076, timestamp diff: 1996 usec
Available: 3024, loop iteration: 32018, diff: 511, timestamp diff: 997 usec
Available: 3072, loop iteration: 32584, diff: 566, timestamp diff: 1000 usec
Available: 3168, loop iteration: 33681, diff: 1097, timestamp diff: 2011 usec
Available: 3216, loop iteration: 34211, diff: 530, timestamp diff: 989 usec
Available: 3264, loop iteration: 34719, diff: 508, timestamp diff: 1006 usec
Available: 3360, loop iteration: 35802, diff: 1083, timestamp diff: 1995 usec
Available: 3408, loop iteration: 36338, diff: 536, timestamp diff: 998 usec
Available: 3456, loop iteration: 36861, diff: 523, timestamp diff: 1002 usec
Available: 3552, loop iteration: 37847, diff: 986, timestamp diff: 1999 usec
Available: 3600, loop iteration: 38394, diff: 547, timestamp diff: 999 usec
Available: 3648, loop iteration: 38933, diff: 539, timestamp diff: 1005 usec
Available: 3744, loop iteration: 39982, diff: 1049, timestamp diff: 1995 usec
Available: 3792, loop iteration: 40542, diff: 560, timestamp diff: 999 usec
Available: 3840, loop iteration: 41078, diff: 536, timestamp diff: 1005 usec
Available: 3936, loop iteration: 42085, diff: 1007, timestamp diff: 1996 usec
Available: 3984, loop iteration: 42616, diff: 531, timestamp diff: 998 usec
Available: 4032, loop iteration: 43143, diff: 527, timestamp diff: 1002 usec

[-- Attachment #3: pcm_avail.c --]
[-- Type: text/x-csrc, Size: 4051 bytes --]

/*
 *  This extra small demo sends silence to your speakers and tests the precision of the reported position.
 */

#include <asoundlib.h>

#include <stdio.h>
#include <stdlib.h>

const char* device;
const int channels = 2;
const snd_pcm_sframes_t period_size = 64;
const int periods = 64;
const int rate = 48000;


int main(int argc, char* argv[])
{
        int err;
	int failed = 0;
        unsigned int j, j_old;
	short *silence;
	snd_pcm_sframes_t avail = -1;
	snd_pcm_uframes_t min_period_size;
	snd_pcm_uframes_t boundary;
	int dir;
	struct timeval tv_old;

	if (argc != 2) {
		fprintf(stderr, "Usage: %s pcm_name\n", argv[0]);
		exit(EXIT_FAILURE);
	}

	device = argv[1];
	printf("======= testing %s =======\n", device);


        snd_pcm_t *handle;
	snd_output_t *out = NULL;

	snd_pcm_hw_params_t *params;
	snd_pcm_sw_params_t *swparams;

	snd_pcm_hw_params_alloca(&params);
	snd_pcm_sw_params_alloca(&swparams);

	snd_output_stdio_attach(&out, stdout, 0);
	silence = calloc(period_size * periods, sizeof(short) * channels);

	if ((err = snd_pcm_open(&handle, device, SND_PCM_STREAM_PLAYBACK, 0)) < 0) {
		fprintf(stderr, "Playback open error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	failed =           (err = snd_pcm_hw_params_any(handle, params)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_rate_resample(handle, params, 1)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_access(handle, params, SND_PCM_ACCESS_RW_INTERLEAVED)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_format(handle, params, SND_PCM_FORMAT_S16)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_channels(handle, params, channels)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_rate(handle, params, rate, 0)) < 0;

	if (failed) {
		fprintf(stderr, "Playback hwparams (access & format) error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	err = snd_pcm_hw_params_get_period_size_min(params, &min_period_size, &dir);
	if (err < 0) {
		fprintf(stderr, "Cannot get minimum period size: %s\n", snd_strerror(err));
	}

	printf("min_period_size: %d frames, dir: %d\n", (int)min_period_size, dir);

	failed =           (err = snd_pcm_hw_params_set_period_size(handle, params, period_size, 0)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_periods(handle, params, periods, 0)) < 0;
	failed = failed || (err = snd_pcm_hw_params(handle, params)) < 0;
	if (failed) {
		fprintf(stderr, "Playback hwparams (period size & periods) error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	err = snd_pcm_hw_params_get_fifo_size(params);
	if (err < 0) {
		fprintf(stderr, "Playback hwparams: can't get FIFO size, error: %s\n", snd_strerror(err));
	} else {
		printf("FIFO size is %d\n", err);
	}

	failed =           (err = snd_pcm_sw_params_current(handle, swparams)) < 0;
	failed = failed || (err = snd_pcm_sw_params_set_start_threshold(handle, swparams, period_size)) < 0;
	failed = failed || (err = snd_pcm_sw_params_set_avail_min(handle, swparams, period_size)) < 0;
	failed = failed || (err = snd_pcm_sw_params(handle, swparams)) < 0;
	if (failed) {
		fprintf(stderr, "Playback swparams error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	snd_pcm_dump(handle, out);
	printf("Playing silence\n");
	fflush(stdout);
	memset(silence, 0, period_size * periods * sizeof(short) * channels);
	err = snd_pcm_writei(handle, silence, period_size * periods);
	if (err < 0) {
		fprintf(stderr, "Playback error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	j = 0;
	j_old = 0;
	gettimeofday(&tv_old, NULL);
	while (1) {
		snd_pcm_sframes_t avail1 = snd_pcm_avail(handle);
		if (avail1 < 0)
			break;
		if (avail != avail1) {
			struct timeval tv;
			gettimeofday(&tv, NULL);
			printf("Available: %d, loop iteration: %d, diff: %d, timestamp diff: %d usec\n", (int)avail1, j, j - j_old,
				(int)((tv.tv_sec - tv_old.tv_sec) * 1000000 + (tv.tv_usec - tv_old.tv_usec)));
			tv_old = tv;
			j_old = j;
		}
		avail = avail1;
		j++;
	}
	snd_pcm_drop(handle);
	snd_pcm_close(handle);

	free(silence);
	return 0;
}

[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>>>
>>> Well, USB-audio has another problem.  USB-audio uses the intermediate
>>> audio ring buffer, and the samples are copied to each URB buffer.  At
>>> each packet complete, the driver copies the rest of sample chunk
>>> again, and advances the hwptr when the packets.  So, the hwptr of
>>> USB-audio is in advance of the actual sample position.  But we provide
>>> the runtime delay information for user-space to correct to the more
>>> accurate sample position.  So far, so good.
>>>
>>> A missing piece in this picture is, however, the position of the
>>> not-yet-queued samples in ring buffer.  Basically you can rewrite /
>>> rewind the sample at most this point, but not farther -- such
>>> in-flight samples can't be modified any longer.  This can be seen a
>>> kind of hardware fifo with a pretty big and non-continuously variable
>>> size during operation.
>>>
>>> In that sense, get_fifo() looks like a candidate for giving such
>>> information, indeed.  But reviving the old (and rather bad working)
>>> API appears dangerous to me.  I'd prefer creating a new API function
>>> instead, if any.
>>>
>>> BTW, because of its design like above, a large (or no) period size
>>> doesn't help for saving power at all with USB-audio.  This should be
>>> considered before the further discussion...
>>
>>
>> Hmm...I was trying to understand this power save argument. I tried to
>> figure out a "typical" URB size by just plugging my headset in, and I
>> saw wMaxPacketSize being 96 and/or 192 bytes.
>> Then, MAX_PACKS is set to either 6 (or 48 for USB 2.0 devices, but this
>> is just a headset).
>>
>> Can this be correct? Does it mean that we are getting interrupts every
>> 192 * 6 bytes (i e, every 6 ms for a 48kHz/stereo/16bit stream)?
>
>
> At least that's how often the position gets updated in the worst case. I
have attached a report for a Logitech USB headset and a test program where
you can modify the buffer and period sizes. A line is logged every time
snd_pcm_avail() returns a different value.
>

How about the result using multiple of 48 frames as period size since min
period size is 48 frames (1 ms) , it seem that your tests are not using the
optimal period size

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

> Hmm...I was trying to understand this power save argument. I tried to
figure out a "typical" URB size by just plugging my headset in, and I saw
wMaxPacketSize being 96 and/or 192 bytes.
> Then, MAX_PACKS is set to either 6 (or 48 for USB 2.0 devices, but this
is just a headset).
>
> Can this be correct? Does it mean that we are getting interrupts every
192 * 6 bytes (i e, every 6 ms for a 48kHz/stereo/16bit stream)?
>
>

Do this mean that the driver report exact one period only when period size
is multiple of wMaxPackerSize ?

Using other period size give bad result , the driver use variable  period
size

hw_ptr does not always at period boundary , seem more like DSP_CAP_BATCH

>From the result , minimum and maximum time difference bewteen hw_ptr change
can varies from 20% to 400%

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Alexander E. Patrakov]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

18.06.2015 08:15, Raymond Yau wrote:

> How about the result using multiple of 48 frames as period size since
> min period size is 48 frames (1 ms) , it seem that your tests are not
> using the optimal period size

Attached. See the second and the third tests in the file. Also, on 
request from David, I have added logging of the delay in addition to avail.

-- 
Alexander E. Patrakov

[-- Attachment #2: pcm_avail.c --]
[-- Type: text/x-csrc, Size: 4194 bytes --]

/*
 *  This extra small demo sends silence to your speakers and tests the precision of the reported position.
 */

#include <asoundlib.h>

#include <stdio.h>
#include <stdlib.h>

const char* device;
const int channels = 2;
const snd_pcm_sframes_t period_size = 960;
const int periods = 4;
const int rate = 48000;


int main(int argc, char* argv[])
{
        int err;
	int failed = 0;
        unsigned int j, j_old;
	short *silence;
	snd_pcm_sframes_t avail = -1, delay = -1;
	snd_pcm_uframes_t min_period_size;
	snd_pcm_uframes_t boundary;
	int dir;
	struct timeval tv_old;

	if (argc != 2) {
		fprintf(stderr, "Usage: %s pcm_name\n", argv[0]);
		exit(EXIT_FAILURE);
	}

	device = argv[1];
	printf("======= testing %s =======\n", device);


        snd_pcm_t *handle;
	snd_output_t *out = NULL;

	snd_pcm_hw_params_t *params;
	snd_pcm_sw_params_t *swparams;

	snd_pcm_hw_params_alloca(&params);
	snd_pcm_sw_params_alloca(&swparams);

	snd_output_stdio_attach(&out, stdout, 0);
	silence = calloc(period_size * periods, sizeof(short) * channels);

	if ((err = snd_pcm_open(&handle, device, SND_PCM_STREAM_PLAYBACK, 0)) < 0) {
		fprintf(stderr, "Playback open error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	failed =           (err = snd_pcm_hw_params_any(handle, params)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_rate_resample(handle, params, 1)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_access(handle, params, SND_PCM_ACCESS_RW_INTERLEAVED)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_format(handle, params, SND_PCM_FORMAT_S16)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_channels(handle, params, channels)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_rate(handle, params, rate, 0)) < 0;

	if (failed) {
		fprintf(stderr, "Playback hwparams (access & format) error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	err = snd_pcm_hw_params_get_period_size_min(params, &min_period_size, &dir);
	if (err < 0) {
		fprintf(stderr, "Cannot get minimum period size: %s\n", snd_strerror(err));
	}

	printf("min_period_size: %d frames, dir: %d\n", (int)min_period_size, dir);

	failed =           (err = snd_pcm_hw_params_set_period_size(handle, params, period_size, 0)) < 0;
	failed = failed || (err = snd_pcm_hw_params_set_periods(handle, params, periods, 0)) < 0;
	failed = failed || (err = snd_pcm_hw_params(handle, params)) < 0;
	if (failed) {
		fprintf(stderr, "Playback hwparams (period size & periods) error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	err = snd_pcm_hw_params_get_fifo_size(params);
	if (err < 0) {
		fprintf(stderr, "Playback hwparams: can't get FIFO size, error: %s\n", snd_strerror(err));
	} else {
		printf("FIFO size is %d\n", err);
	}

	failed =           (err = snd_pcm_sw_params_current(handle, swparams)) < 0;
	failed = failed || (err = snd_pcm_sw_params_set_start_threshold(handle, swparams, period_size)) < 0;
	failed = failed || (err = snd_pcm_sw_params_set_avail_min(handle, swparams, period_size)) < 0;
	failed = failed || (err = snd_pcm_sw_params(handle, swparams)) < 0;
	if (failed) {
		fprintf(stderr, "Playback swparams error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	snd_pcm_dump(handle, out);
	printf("Playing silence\n");
	fflush(stdout);
	memset(silence, 0, period_size * periods * sizeof(short) * channels);
	err = snd_pcm_writei(handle, silence, period_size * periods);
	if (err < 0) {
		fprintf(stderr, "Playback error: %s\n", snd_strerror(err));
		exit(EXIT_FAILURE);
	}

	j = 0;
	j_old = 0;
	gettimeofday(&tv_old, NULL);
	while (1) {
		snd_pcm_sframes_t avail1;
		snd_pcm_sframes_t delay1;
		err = snd_pcm_avail_delay(handle, &avail1, &delay1);
		if (err < 0 || avail1 < 0)
			break;
		if (avail != avail1 || delay != delay1) {
			struct timeval tv;
			gettimeofday(&tv, NULL);
			printf("Available: %d, delay: %d, loop iteration: %d, diff: %d, timestamp diff: %d usec\n", (int)avail1, (int)delay1, j, j - j_old,
				(int)((tv.tv_sec - tv_old.tv_sec) * 1000000 + (tv.tv_usec - tv_old.tv_usec)));
			tv_old = tv;
			j_old = j;
		}
		avail = avail1;
		delay = delay1;
		j++;
	}
	snd_pcm_drop(handle);
	snd_pcm_close(handle);

	free(silence);
	return 0;
}

[-- Attachment #3: usb_sound_timings_v2.txt --]
[-- Type: text/plain, Size: 27195 bytes --]

======= testing hw:2 =======
min_period_size: 48 frames, dir: 0
FIFO size is 0
Hardware PCM card 2 'C-Media USB Headphone Set' 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, delay: 4096, loop iteration: 0, diff: 0, timestamp diff: 6 usec
Available: 288, delay: 4096, loop iteration: 5038, diff: 5038, timestamp diff: 6014 usec
Available: 288, delay: 4048, loop iteration: 5107, diff: 69, timestamp diff: 221 usec
Available: 288, delay: 4000, loop iteration: 5453, diff: 346, timestamp diff: 1001 usec
Available: 288, delay: 3952, loop iteration: 5787, diff: 334, timestamp diff: 1001 usec
Available: 288, delay: 3904, loop iteration: 6132, diff: 345, timestamp diff: 999 usec
Available: 288, delay: 3856, loop iteration: 6467, diff: 335, timestamp diff: 1000 usec
Available: 288, delay: 3808, loop iteration: 6814, diff: 347, timestamp diff: 1000 usec
Available: 528, delay: 3808, loop iteration: 7078, diff: 264, timestamp diff: 785 usec
Available: 528, delay: 3760, loop iteration: 7153, diff: 75, timestamp diff: 215 usec
Available: 528, delay: 3712, loop iteration: 7519, diff: 366, timestamp diff: 1000 usec
Available: 528, delay: 3664, loop iteration: 7881, diff: 362, timestamp diff: 999 usec
Available: 528, delay: 3616, loop iteration: 8224, diff: 343, timestamp diff: 1001 usec
Available: 528, delay: 3568, loop iteration: 8589, diff: 365, timestamp diff: 1000 usec
Available: 768, delay: 3568, loop iteration: 9231, diff: 642, timestamp diff: 1837 usec
Available: 768, delay: 3520, loop iteration: 9276, diff: 45, timestamp diff: 164 usec
Available: 768, delay: 3472, loop iteration: 9642, diff: 366, timestamp diff: 998 usec
Available: 768, delay: 3424, loop iteration: 10007, diff: 365, timestamp diff: 1001 usec
Available: 768, delay: 3376, loop iteration: 10368, diff: 361, timestamp diff: 999 usec
Available: 768, delay: 3328, loop iteration: 10712, diff: 344, timestamp diff: 999 usec
Available: 1056, delay: 3328, loop iteration: 11363, diff: 651, timestamp diff: 1784 usec
Available: 1056, delay: 3280, loop iteration: 11440, diff: 77, timestamp diff: 218 usec
Available: 1056, delay: 3232, loop iteration: 11795, diff: 355, timestamp diff: 1000 usec
Available: 1056, delay: 3184, loop iteration: 12180, diff: 385, timestamp diff: 1000 usec
Available: 1056, delay: 3136, loop iteration: 12566, diff: 386, timestamp diff: 1000 usec
Available: 1056, delay: 3088, loop iteration: 12952, diff: 386, timestamp diff: 999 usec
Available: 1056, delay: 3040, loop iteration: 13248, diff: 296, timestamp diff: 830 usec
Available: 1296, delay: 3088, loop iteration: 13249, diff: 1, timestamp diff: 6 usec
Available: 1296, delay: 3040, loop iteration: 13283, diff: 34, timestamp diff: 163 usec
Available: 1296, delay: 2992, loop iteration: 13669, diff: 386, timestamp diff: 1001 usec
Available: 1296, delay: 2944, loop iteration: 14056, diff: 387, timestamp diff: 1001 usec
Available: 1296, delay: 2896, loop iteration: 14442, diff: 386, timestamp diff: 999 usec
Available: 1296, delay: 2848, loop iteration: 14828, diff: 386, timestamp diff: 999 usec
Available: 1536, delay: 2848, loop iteration: 15121, diff: 293, timestamp diff: 828 usec
Available: 1536, delay: 2800, loop iteration: 15186, diff: 65, timestamp diff: 173 usec
Available: 1536, delay: 2752, loop iteration: 15577, diff: 391, timestamp diff: 999 usec
Available: 1536, delay: 2704, loop iteration: 15964, diff: 387, timestamp diff: 1001 usec
Available: 1536, delay: 2656, loop iteration: 16350, diff: 386, timestamp diff: 999 usec
Available: 1536, delay: 2608, loop iteration: 16737, diff: 387, timestamp diff: 1001 usec
Available: 1536, delay: 2560, loop iteration: 17105, diff: 368, timestamp diff: 999 usec
Available: 1824, delay: 2560, loop iteration: 17350, diff: 245, timestamp diff: 801 usec
Available: 1824, delay: 2512, loop iteration: 17406, diff: 56, timestamp diff: 201 usec
Available: 1824, delay: 2464, loop iteration: 17788, diff: 382, timestamp diff: 999 usec
Available: 1824, delay: 2416, loop iteration: 18170, diff: 382, timestamp diff: 999 usec
Available: 1824, delay: 2368, loop iteration: 18554, diff: 384, timestamp diff: 1001 usec
Available: 1824, delay: 2320, loop iteration: 18941, diff: 387, timestamp diff: 1001 usec
Available: 2064, delay: 2320, loop iteration: 19241, diff: 300, timestamp diff: 832 usec
Available: 2064, delay: 2272, loop iteration: 19270, diff: 29, timestamp diff: 169 usec
Available: 2064, delay: 2224, loop iteration: 19671, diff: 401, timestamp diff: 996 usec
Available: 2064, delay: 2176, loop iteration: 20080, diff: 409, timestamp diff: 1002 usec
Available: 2064, delay: 2128, loop iteration: 20488, diff: 408, timestamp diff: 1000 usec
Available: 2064, delay: 2080, loop iteration: 20896, diff: 408, timestamp diff: 1000 usec
Available: 2304, delay: 2080, loop iteration: 21204, diff: 308, timestamp diff: 769 usec
Available: 2304, delay: 2032, loop iteration: 21296, diff: 92, timestamp diff: 230 usec
Available: 2304, delay: 1984, loop iteration: 21702, diff: 406, timestamp diff: 1001 usec
Available: 2304, delay: 1936, loop iteration: 22107, diff: 405, timestamp diff: 999 usec
Available: 2304, delay: 1888, loop iteration: 22510, diff: 403, timestamp diff: 1001 usec
Available: 2304, delay: 1840, loop iteration: 22922, diff: 412, timestamp diff: 1000 usec
Available: 2304, delay: 1792, loop iteration: 23328, diff: 406, timestamp diff: 999 usec
Available: 2592, delay: 1792, loop iteration: 23643, diff: 315, timestamp diff: 831 usec
Available: 2592, delay: 1744, loop iteration: 23710, diff: 67, timestamp diff: 170 usec
Available: 2592, delay: 1696, loop iteration: 24116, diff: 406, timestamp diff: 999 usec
Available: 2592, delay: 1648, loop iteration: 24523, diff: 407, timestamp diff: 1001 usec
Available: 2592, delay: 1600, loop iteration: 24923, diff: 400, timestamp diff: 999 usec
Available: 2592, delay: 1552, loop iteration: 25334, diff: 411, timestamp diff: 999 usec
Available: 2592, delay: 1504, loop iteration: 25645, diff: 311, timestamp diff: 822 usec
Available: 2832, delay: 1552, loop iteration: 25646, diff: 1, timestamp diff: 6 usec
Available: 2832, delay: 1504, loop iteration: 25712, diff: 66, timestamp diff: 174 usec
Available: 2832, delay: 1456, loop iteration: 26123, diff: 411, timestamp diff: 999 usec
Available: 2832, delay: 1408, loop iteration: 26524, diff: 401, timestamp diff: 999 usec
Available: 2832, delay: 1360, loop iteration: 26940, diff: 416, timestamp diff: 1000 usec
Available: 2832, delay: 1312, loop iteration: 27343, diff: 403, timestamp diff: 1002 usec
Available: 2832, delay: 1264, loop iteration: 27673, diff: 330, timestamp diff: 764 usec
Available: 3072, delay: 1312, loop iteration: 27674, diff: 1, timestamp diff: 6 usec
Available: 3072, delay: 1264, loop iteration: 27769, diff: 95, timestamp diff: 228 usec
Available: 3072, delay: 1216, loop iteration: 28198, diff: 429, timestamp diff: 1002 usec
Available: 3072, delay: 1168, loop iteration: 28613, diff: 415, timestamp diff: 999 usec
Available: 3072, delay: 1120, loop iteration: 29038, diff: 425, timestamp diff: 999 usec
Available: 3072, delay: 1072, loop iteration: 29462, diff: 424, timestamp diff: 1002 usec
Available: 3072, delay: 1024, loop iteration: 29885, diff: 423, timestamp diff: 998 usec
Available: 3360, delay: 1024, loop iteration: 30205, diff: 320, timestamp diff: 820 usec
Available: 3360, delay: 976, loop iteration: 30279, diff: 74, timestamp diff: 180 usec
Available: 3360, delay: 928, loop iteration: 30703, diff: 424, timestamp diff: 1002 usec
Available: 3360, delay: 880, loop iteration: 31126, diff: 423, timestamp diff: 998 usec
Available: 3360, delay: 832, loop iteration: 31550, diff: 424, timestamp diff: 1001 usec
Available: 3360, delay: 784, loop iteration: 31973, diff: 423, timestamp diff: 999 usec
Available: 3600, delay: 784, loop iteration: 32301, diff: 328, timestamp diff: 828 usec
Available: 3600, delay: 736, loop iteration: 32372, diff: 71, timestamp diff: 172 usec
Available: 3600, delay: 688, loop iteration: 32796, diff: 424, timestamp diff: 1001 usec
Available: 3600, delay: 640, loop iteration: 33220, diff: 424, timestamp diff: 1000 usec
Available: 3600, delay: 592, loop iteration: 33635, diff: 415, timestamp diff: 999 usec
Available: 3600, delay: 544, loop iteration: 34059, diff: 424, timestamp diff: 1001 usec
Available: 3600, delay: 496, loop iteration: 34381, diff: 322, timestamp diff: 818 usec
Available: 3840, delay: 544, loop iteration: 34382, diff: 1, timestamp diff: 63 usec
Available: 3840, delay: 496, loop iteration: 34432, diff: 50, timestamp diff: 118 usec
Available: 3840, delay: 448, loop iteration: 34855, diff: 423, timestamp diff: 1000 usec
Available: 3840, delay: 400, loop iteration: 35279, diff: 424, timestamp diff: 1001 usec
Available: 3840, delay: 352, loop iteration: 35692, diff: 413, timestamp diff: 1000 usec
Available: 3840, delay: 304, loop iteration: 36129, diff: 437, timestamp diff: 1000 usec
Available: 3840, delay: 256, loop iteration: 36575, diff: 446, timestamp diff: 1000 usec
======= testing hw:2 =======
min_period_size: 48 frames, dir: 0
FIFO size is 0
Hardware PCM card 2 'C-Media USB Headphone Set' 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  : 3072
  period_size  : 96
  period_time  : 2000
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 96
  period_event : 0
  start_threshold  : 96
  stop_threshold   : 3072
  silence_threshold: 0
  silence_size : 0
  boundary     : 6917529027641081856
  appl_ptr     : 0
  hw_ptr       : 0
Playing silence
Available: 0, delay: 3072, loop iteration: 0, diff: 0, timestamp diff: 6 usec
Available: 96, delay: 3072, loop iteration: 1585, diff: 1585, timestamp diff: 2267 usec
Available: 96, delay: 3024, loop iteration: 1654, diff: 69, timestamp diff: 219 usec
Available: 96, delay: 2976, loop iteration: 2012, diff: 358, timestamp diff: 999 usec
Available: 192, delay: 2976, loop iteration: 2265, diff: 253, timestamp diff: 779 usec
Available: 192, delay: 2928, loop iteration: 2337, diff: 72, timestamp diff: 221 usec
Available: 192, delay: 2880, loop iteration: 2535, diff: 198, timestamp diff: 999 usec
Available: 288, delay: 2880, loop iteration: 2780, diff: 245, timestamp diff: 776 usec
Available: 288, delay: 2832, loop iteration: 2844, diff: 64, timestamp diff: 225 usec
Available: 288, delay: 2784, loop iteration: 3116, diff: 272, timestamp diff: 1004 usec
Available: 384, delay: 2784, loop iteration: 3316, diff: 200, timestamp diff: 776 usec
Available: 384, delay: 2736, loop iteration: 3371, diff: 55, timestamp diff: 220 usec
Available: 384, delay: 2688, loop iteration: 3631, diff: 260, timestamp diff: 1002 usec
Available: 480, delay: 2688, loop iteration: 3895, diff: 264, timestamp diff: 780 usec
Available: 480, delay: 2640, loop iteration: 3961, diff: 66, timestamp diff: 220 usec
Available: 480, delay: 2592, loop iteration: 4309, diff: 348, timestamp diff: 999 usec
Available: 576, delay: 2592, loop iteration: 4557, diff: 248, timestamp diff: 789 usec
Available: 576, delay: 2544, loop iteration: 4610, diff: 53, timestamp diff: 211 usec
Available: 576, delay: 2496, loop iteration: 4955, diff: 345, timestamp diff: 999 usec
Available: 672, delay: 2496, loop iteration: 5225, diff: 270, timestamp diff: 773 usec
Available: 672, delay: 2448, loop iteration: 5301, diff: 76, timestamp diff: 227 usec
Available: 672, delay: 2400, loop iteration: 5663, diff: 362, timestamp diff: 1000 usec
Available: 768, delay: 2400, loop iteration: 5940, diff: 277, timestamp diff: 773 usec
Available: 768, delay: 2352, loop iteration: 6020, diff: 80, timestamp diff: 228 usec
Available: 768, delay: 2304, loop iteration: 6386, diff: 366, timestamp diff: 999 usec
Available: 864, delay: 2304, loop iteration: 6669, diff: 283, timestamp diff: 773 usec
Available: 864, delay: 2256, loop iteration: 6729, diff: 60, timestamp diff: 228 usec
Available: 864, delay: 2208, loop iteration: 7087, diff: 358, timestamp diff: 999 usec
Available: 960, delay: 2208, loop iteration: 7373, diff: 286, timestamp diff: 779 usec
Available: 960, delay: 2160, loop iteration: 7443, diff: 70, timestamp diff: 220 usec
Available: 960, delay: 2112, loop iteration: 7804, diff: 361, timestamp diff: 1000 usec
Available: 1056, delay: 2112, loop iteration: 8079, diff: 275, timestamp diff: 771 usec
Available: 1056, delay: 2064, loop iteration: 8160, diff: 81, timestamp diff: 230 usec
Available: 1056, delay: 2016, loop iteration: 8524, diff: 364, timestamp diff: 1001 usec
Available: 1152, delay: 2016, loop iteration: 8778, diff: 254, timestamp diff: 770 usec
Available: 1152, delay: 1968, loop iteration: 8856, diff: 78, timestamp diff: 230 usec
Available: 1152, delay: 1920, loop iteration: 9221, diff: 365, timestamp diff: 999 usec
Available: 1248, delay: 1920, loop iteration: 9503, diff: 282, timestamp diff: 774 usec
Available: 1248, delay: 1872, loop iteration: 9574, diff: 71, timestamp diff: 226 usec
Available: 1248, delay: 1824, loop iteration: 9940, diff: 366, timestamp diff: 999 usec
Available: 1344, delay: 1824, loop iteration: 10203, diff: 263, timestamp diff: 777 usec
Available: 1344, delay: 1776, loop iteration: 10280, diff: 77, timestamp diff: 224 usec
Available: 1344, delay: 1728, loop iteration: 10641, diff: 361, timestamp diff: 1001 usec
Available: 1440, delay: 1728, loop iteration: 10907, diff: 266, timestamp diff: 770 usec
Available: 1440, delay: 1680, loop iteration: 10987, diff: 80, timestamp diff: 228 usec
Available: 1440, delay: 1632, loop iteration: 11358, diff: 371, timestamp diff: 1000 usec
Available: 1536, delay: 1632, loop iteration: 11644, diff: 286, timestamp diff: 775 usec
Available: 1536, delay: 1584, loop iteration: 11720, diff: 76, timestamp diff: 226 usec
Available: 1536, delay: 1536, loop iteration: 12079, diff: 359, timestamp diff: 998 usec
Available: 1632, delay: 1536, loop iteration: 12361, diff: 282, timestamp diff: 778 usec
Available: 1632, delay: 1488, loop iteration: 12440, diff: 79, timestamp diff: 224 usec
Available: 1632, delay: 1440, loop iteration: 12805, diff: 365, timestamp diff: 998 usec
Available: 1728, delay: 1440, loop iteration: 13082, diff: 277, timestamp diff: 770 usec
Available: 1728, delay: 1392, loop iteration: 13163, diff: 81, timestamp diff: 232 usec
Available: 1728, delay: 1344, loop iteration: 13525, diff: 362, timestamp diff: 1001 usec
Available: 1824, delay: 1344, loop iteration: 13803, diff: 278, timestamp diff: 768 usec
Available: 1824, delay: 1296, loop iteration: 13861, diff: 58, timestamp diff: 231 usec
Available: 1824, delay: 1248, loop iteration: 14221, diff: 360, timestamp diff: 999 usec
Available: 1920, delay: 1248, loop iteration: 14522, diff: 301, timestamp diff: 772 usec
Available: 1920, delay: 1200, loop iteration: 14588, diff: 66, timestamp diff: 229 usec
Available: 1920, delay: 1152, loop iteration: 14970, diff: 382, timestamp diff: 1000 usec
Available: 2016, delay: 1152, loop iteration: 15270, diff: 300, timestamp diff: 770 usec
Available: 2016, delay: 1104, loop iteration: 15350, diff: 80, timestamp diff: 230 usec
Available: 2016, delay: 1056, loop iteration: 15733, diff: 383, timestamp diff: 999 usec
Available: 2112, delay: 1056, loop iteration: 16013, diff: 280, timestamp diff: 770 usec
Available: 2112, delay: 1008, loop iteration: 16097, diff: 84, timestamp diff: 231 usec
Available: 2112, delay: 960, loop iteration: 16464, diff: 367, timestamp diff: 999 usec
Available: 2208, delay: 960, loop iteration: 16746, diff: 282, timestamp diff: 782 usec
Available: 2208, delay: 912, loop iteration: 16822, diff: 76, timestamp diff: 218 usec
Available: 2208, delay: 864, loop iteration: 17183, diff: 361, timestamp diff: 999 usec
Available: 2304, delay: 864, loop iteration: 17465, diff: 282, timestamp diff: 784 usec
Available: 2304, delay: 816, loop iteration: 17535, diff: 70, timestamp diff: 216 usec
Available: 2304, delay: 768, loop iteration: 17898, diff: 363, timestamp diff: 1001 usec
Available: 2400, delay: 768, loop iteration: 18180, diff: 282, timestamp diff: 775 usec
Available: 2400, delay: 720, loop iteration: 18258, diff: 78, timestamp diff: 225 usec
Available: 2400, delay: 672, loop iteration: 18639, diff: 381, timestamp diff: 1001 usec
Available: 2496, delay: 672, loop iteration: 18934, diff: 295, timestamp diff: 767 usec
Available: 2496, delay: 624, loop iteration: 19021, diff: 87, timestamp diff: 232 usec
Available: 2496, delay: 576, loop iteration: 19400, diff: 379, timestamp diff: 1000 usec
Available: 2592, delay: 576, loop iteration: 19698, diff: 298, timestamp diff: 770 usec
Available: 2592, delay: 528, loop iteration: 19784, diff: 86, timestamp diff: 229 usec
Available: 2592, delay: 480, loop iteration: 20174, diff: 390, timestamp diff: 1000 usec
Available: 2688, delay: 480, loop iteration: 20480, diff: 306, timestamp diff: 772 usec
Available: 2688, delay: 432, loop iteration: 20564, diff: 84, timestamp diff: 230 usec
Available: 2688, delay: 384, loop iteration: 20938, diff: 374, timestamp diff: 998 usec
Available: 2784, delay: 384, loop iteration: 21208, diff: 270, timestamp diff: 769 usec
Available: 2784, delay: 336, loop iteration: 21270, diff: 62, timestamp diff: 231 usec
Available: 2784, delay: 288, loop iteration: 21671, diff: 401, timestamp diff: 1000 usec
Available: 2880, delay: 288, loop iteration: 21991, diff: 320, timestamp diff: 768 usec
Available: 2880, delay: 240, loop iteration: 22082, diff: 91, timestamp diff: 232 usec
Available: 2880, delay: 192, loop iteration: 22487, diff: 405, timestamp diff: 1001 usec
Available: 2976, delay: 192, loop iteration: 22797, diff: 310, timestamp diff: 768 usec
Available: 2976, delay: 144, loop iteration: 22885, diff: 88, timestamp diff: 231 usec
Available: 2976, delay: 96, loop iteration: 23281, diff: 396, timestamp diff: 1000 usec
======= testing hw:2 =======
min_period_size: 48 frames, dir: 0
FIFO size is 0
Hardware PCM card 2 'C-Media USB Headphone Set' 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  : 3840
  period_size  : 960
  period_time  : 20000
  tstamp_mode  : NONE
  tstamp_type  : MONOTONIC
  period_step  : 1
  avail_min    : 960
  period_event : 0
  start_threshold  : 960
  stop_threshold   : 3840
  silence_threshold: 0
  silence_size : 0
  boundary     : 8646911284551352320
  appl_ptr     : 0
  hw_ptr       : 0
Playing silence
Available: 0, delay: 3840, loop iteration: 0, diff: 0, timestamp diff: 7 usec
Available: 240, delay: 3840, loop iteration: 3832, diff: 3832, timestamp diff: 5214 usec
Available: 240, delay: 3792, loop iteration: 3900, diff: 68, timestamp diff: 213 usec
Available: 240, delay: 3744, loop iteration: 4190, diff: 290, timestamp diff: 998 usec
Available: 240, delay: 3696, loop iteration: 4505, diff: 315, timestamp diff: 999 usec
Available: 240, delay: 3648, loop iteration: 4826, diff: 321, timestamp diff: 1000 usec
Available: 240, delay: 3600, loop iteration: 5146, diff: 320, timestamp diff: 1002 usec
Available: 480, delay: 3600, loop iteration: 5389, diff: 243, timestamp diff: 779 usec
Available: 480, delay: 3552, loop iteration: 5456, diff: 67, timestamp diff: 220 usec
Available: 480, delay: 3504, loop iteration: 5774, diff: 318, timestamp diff: 1000 usec
Available: 480, delay: 3456, loop iteration: 6092, diff: 318, timestamp diff: 1001 usec
Available: 480, delay: 3408, loop iteration: 6406, diff: 314, timestamp diff: 1000 usec
Available: 480, delay: 3360, loop iteration: 6727, diff: 321, timestamp diff: 998 usec
Available: 720, delay: 3360, loop iteration: 6968, diff: 241, timestamp diff: 779 usec
Available: 720, delay: 3312, loop iteration: 7037, diff: 69, timestamp diff: 223 usec
Available: 720, delay: 3264, loop iteration: 7354, diff: 317, timestamp diff: 997 usec
Available: 720, delay: 3216, loop iteration: 7672, diff: 318, timestamp diff: 1001 usec
Available: 720, delay: 3168, loop iteration: 7992, diff: 320, timestamp diff: 1002 usec
Available: 720, delay: 3120, loop iteration: 8312, diff: 320, timestamp diff: 999 usec
Available: 960, delay: 3120, loop iteration: 8558, diff: 246, timestamp diff: 786 usec
Available: 960, delay: 3072, loop iteration: 8626, diff: 68, timestamp diff: 213 usec
Available: 960, delay: 3024, loop iteration: 8944, diff: 318, timestamp diff: 1000 usec
Available: 960, delay: 2976, loop iteration: 9239, diff: 295, timestamp diff: 1000 usec
Available: 960, delay: 2928, loop iteration: 9523, diff: 284, timestamp diff: 1000 usec
Available: 960, delay: 2880, loop iteration: 9828, diff: 305, timestamp diff: 1001 usec
Available: 1200, delay: 2880, loop iteration: 10072, diff: 244, timestamp diff: 771 usec
Available: 1200, delay: 2832, loop iteration: 10145, diff: 73, timestamp diff: 227 usec
Available: 1200, delay: 2784, loop iteration: 10463, diff: 318, timestamp diff: 1000 usec
Available: 1200, delay: 2736, loop iteration: 10773, diff: 310, timestamp diff: 1001 usec
Available: 1200, delay: 2688, loop iteration: 11094, diff: 321, timestamp diff: 1000 usec
Available: 1200, delay: 2640, loop iteration: 11409, diff: 315, timestamp diff: 999 usec
Available: 1440, delay: 2640, loop iteration: 11655, diff: 246, timestamp diff: 781 usec
Available: 1440, delay: 2592, loop iteration: 11724, diff: 69, timestamp diff: 220 usec
Available: 1440, delay: 2544, loop iteration: 12044, diff: 320, timestamp diff: 1000 usec
Available: 1440, delay: 2496, loop iteration: 12365, diff: 321, timestamp diff: 1001 usec
Available: 1440, delay: 2448, loop iteration: 12687, diff: 322, timestamp diff: 1000 usec
Available: 1440, delay: 2400, loop iteration: 13010, diff: 323, timestamp diff: 999 usec
Available: 1680, delay: 2400, loop iteration: 13253, diff: 243, timestamp diff: 774 usec
Available: 1680, delay: 2352, loop iteration: 13325, diff: 72, timestamp diff: 226 usec
Available: 1680, delay: 2304, loop iteration: 13646, diff: 321, timestamp diff: 999 usec
Available: 1680, delay: 2256, loop iteration: 13967, diff: 321, timestamp diff: 1001 usec
Available: 1680, delay: 2208, loop iteration: 14288, diff: 321, timestamp diff: 1001 usec
Available: 1680, delay: 2160, loop iteration: 14597, diff: 309, timestamp diff: 998 usec
Available: 1920, delay: 2160, loop iteration: 14868, diff: 271, timestamp diff: 782 usec
Available: 1920, delay: 2112, loop iteration: 14939, diff: 71, timestamp diff: 220 usec
Available: 1920, delay: 2064, loop iteration: 15278, diff: 339, timestamp diff: 999 usec
Available: 1920, delay: 2016, loop iteration: 15612, diff: 334, timestamp diff: 1001 usec
Available: 1920, delay: 1968, loop iteration: 15913, diff: 301, timestamp diff: 998 usec
Available: 1920, delay: 1920, loop iteration: 16233, diff: 320, timestamp diff: 999 usec
Available: 2160, delay: 1920, loop iteration: 16483, diff: 250, timestamp diff: 780 usec
Available: 2160, delay: 1872, loop iteration: 16549, diff: 66, timestamp diff: 221 usec
Available: 2160, delay: 1824, loop iteration: 16841, diff: 292, timestamp diff: 1001 usec
Available: 2160, delay: 1776, loop iteration: 17049, diff: 208, timestamp diff: 1863 usec
Available: 2160, delay: 1680, loop iteration: 17050, diff: 1, timestamp diff: 1399 usec
Available: 2400, delay: 1680, loop iteration: 17216, diff: 166, timestamp diff: 518 usec
Available: 2400, delay: 1632, loop iteration: 17285, diff: 69, timestamp diff: 219 usec
Available: 2400, delay: 1584, loop iteration: 17549, diff: 264, timestamp diff: 1001 usec
Available: 2400, delay: 1536, loop iteration: 17825, diff: 276, timestamp diff: 999 usec
Available: 2400, delay: 1488, loop iteration: 18069, diff: 244, timestamp diff: 1002 usec
Available: 2400, delay: 1440, loop iteration: 18319, diff: 250, timestamp diff: 999 usec
Available: 2640, delay: 1440, loop iteration: 18496, diff: 177, timestamp diff: 788 usec
Available: 2640, delay: 1392, loop iteration: 18548, diff: 52, timestamp diff: 211 usec
Available: 2640, delay: 1344, loop iteration: 18789, diff: 241, timestamp diff: 1002 usec
Available: 2640, delay: 1296, loop iteration: 19040, diff: 251, timestamp diff: 997 usec
Available: 2640, delay: 1248, loop iteration: 19129, diff: 89, timestamp diff: 1005 usec
Available: 2640, delay: 1200, loop iteration: 19374, diff: 245, timestamp diff: 997 usec
Available: 2880, delay: 1200, loop iteration: 19567, diff: 193, timestamp diff: 782 usec
Available: 2880, delay: 1152, loop iteration: 19624, diff: 57, timestamp diff: 218 usec
Available: 2880, delay: 1104, loop iteration: 19881, diff: 257, timestamp diff: 999 usec
Available: 2880, delay: 1056, loop iteration: 20124, diff: 243, timestamp diff: 999 usec
Available: 2880, delay: 1008, loop iteration: 20366, diff: 242, timestamp diff: 1003 usec
Available: 2880, delay: 960, loop iteration: 20628, diff: 262, timestamp diff: 1000 usec
Available: 3120, delay: 960, loop iteration: 20876, diff: 248, timestamp diff: 774 usec
Available: 3120, delay: 912, loop iteration: 20960, diff: 84, timestamp diff: 225 usec
Available: 3120, delay: 864, loop iteration: 21346, diff: 386, timestamp diff: 998 usec
Available: 3120, delay: 816, loop iteration: 21736, diff: 390, timestamp diff: 1000 usec
Available: 3120, delay: 768, loop iteration: 22150, diff: 414, timestamp diff: 1000 usec
Available: 3120, delay: 720, loop iteration: 22561, diff: 411, timestamp diff: 1001 usec
Available: 3360, delay: 720, loop iteration: 22872, diff: 311, timestamp diff: 772 usec
Available: 3360, delay: 672, loop iteration: 22964, diff: 92, timestamp diff: 227 usec
Available: 3360, delay: 624, loop iteration: 23370, diff: 406, timestamp diff: 1000 usec
Available: 3360, delay: 576, loop iteration: 23756, diff: 386, timestamp diff: 1000 usec
Available: 3360, delay: 528, loop iteration: 24166, diff: 410, timestamp diff: 1001 usec
Available: 3360, delay: 480, loop iteration: 24579, diff: 413, timestamp diff: 998 usec
Available: 3600, delay: 480, loop iteration: 24889, diff: 310, timestamp diff: 772 usec
Available: 3600, delay: 432, loop iteration: 24983, diff: 94, timestamp diff: 230 usec
Available: 3600, delay: 384, loop iteration: 25391, diff: 408, timestamp diff: 1000 usec
Available: 3600, delay: 336, loop iteration: 25799, diff: 408, timestamp diff: 998 usec
Available: 3600, delay: 288, loop iteration: 26209, diff: 410, timestamp diff: 1001 usec
Available: 3600, delay: 240, loop iteration: 26618, diff: 409, timestamp diff: 1001 usec

[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Takashi Iwai]

At Wed, 17 Jun 2015 17:09:41 +0200,
David Henningsson wrote:
> 
> 
> 
> On 2015-06-17 11:19, Takashi Iwai wrote:
> > Well, USB-audio has another problem.  USB-audio uses the intermediate
> > audio ring buffer, and the samples are copied to each URB buffer.  At
> > each packet complete, the driver copies the rest of sample chunk
> > again, and advances the hwptr when the packets.  So, the hwptr of
> > USB-audio is in advance of the actual sample position.  But we provide
> > the runtime delay information for user-space to correct to the more
> > accurate sample position.  So far, so good.
> >
> > A missing piece in this picture is, however, the position of the
> > not-yet-queued samples in ring buffer.  Basically you can rewrite /
> > rewind the sample at most this point, but not farther -- such
> > in-flight samples can't be modified any longer.  This can be seen a
> > kind of hardware fifo with a pretty big and non-continuously variable
> > size during operation.
> >
> > In that sense, get_fifo() looks like a candidate for giving such
> > information, indeed.  But reviving the old (and rather bad working)
> > API appears dangerous to me.  I'd prefer creating a new API function
> > instead, if any.
> >
> > BTW, because of its design like above, a large (or no) period size
> > doesn't help for saving power at all with USB-audio.  This should be
> > considered before the further discussion...
> 
> Hmm...I was trying to understand this power save argument. I tried to 
> figure out a "typical" URB size by just plugging my headset in, and I 
> saw wMaxPacketSize being 96 and/or 192 bytes.
> Then, MAX_PACKS is set to either 6 (or 48 for USB 2.0 devices, but this 
> is just a headset).
> 
> Can this be correct? Does it mean that we are getting interrupts every 
> 192 * 6 bytes (i e, every 6 ms for a 48kHz/stereo/16bit stream)?

The driver can build up a URB containing multiple packets, so the
wakeups can be reduced in some level.  But, then the hwptr update also
suffers, and more badly, the in-flight size also increases -- both are
bad for sample mixing, obviously.


Takashi

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

> > > Well, USB-audio has another problem.  USB-audio uses the intermediate
> > > audio ring buffer, and the samples are copied to each URB buffer.  At
> > > each packet complete, the driver copies the rest of sample chunk
> > > again, and advances the hwptr when the packets.  So, the hwptr of
> > > USB-audio is in advance of the actual sample position.  But we provide
> > > the runtime delay information for user-space to correct to the more
> > > accurate sample position.  So far, so good.
> > >
> > > A missing piece in this picture is, however, the position of the
> > > not-yet-queued samples in ring buffer.  Basically you can rewrite /
> > > rewind the sample at most this point, but not farther -- such
> > > in-flight samples can't be modified any longer.  This can be seen a
> > > kind of hardware fifo with a pretty big and non-continuously variable
> > > size during operation.
> > >
> > > In that sense, get_fifo() looks like a candidate for giving such
> > > information, indeed.  But reviving the old (and rather bad working)
> > > API appears dangerous to me.  I'd prefer creating a new API function
> > > instead, if any.
> > >
> > > BTW, because of its design like above, a large (or no) period size
> > > doesn't help for saving power at all with USB-audio.  This should be
> > > considered before the further discussion...
> >
> > Hmm...I was trying to understand this power save argument. I tried to
> > figure out a "typical" URB size by just plugging my headset in, and I
> > saw wMaxPacketSize being 96 and/or 192 bytes.
> > Then, MAX_PACKS is set to either 6 (or 48 for USB 2.0 devices, but this
> > is just a headset).
> >
> > Can this be correct? Does it mean that we are getting interrupts every
> > 192 * 6 bytes (i e, every 6 ms for a 48kHz/stereo/16bit stream)?
>
> The driver can build up a URB containing multiple packets, so the
> wakeups can be reduced in some level.  But, then the hwptr update also
> suffers, and more badly, the in-flight size also increases -- both are
> bad for sample mixing, obviously.
>

http://lxr.free-electrons.com/ident?i=SNDRV_PCM_INFO_BATCH

If info batch represent exact one period,

do you mean snd-intel8x0 is worst or better ?

How about firewire which also use packets ?

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

> > Hmm...I was trying to understand this power save argument. I tried to
> > figure out a "typical" URB size by just plugging my headset in, and I
> > saw wMaxPacketSize being 96 and/or 192 bytes.
> > Then, MAX_PACKS is set to either 6 (or 48 for USB 2.0 devices, but this
> > is just a headset).
> >
> > Can this be correct? Does it mean that we are getting interrupts every
> > 192 * 6 bytes (i e, every 6 ms for a 48kHz/stereo/16bit stream)?
>
> The driver can build up a URB containing multiple packets, so the
> wakeups can be reduced in some level.  But, then the hwptr update also
> suffers, and more badly, the in-flight size also increases -- both are
> bad for sample mixing, obviously.
>
>
>

Do it mean that period_bytes_max is wMaxPacketSize * MAX_PACKS, driver only
support small period sizes ?

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>
> DMA_RESIDUE_GRANULARITY_BURST means it can report the position with a
granularity of a few samples. Typically half the audio FIFO size.
>
>

How many soc driver/platform dma engine support
DMA_RESIDUE_GRANULARITY_BURST ?

Are all soc audio driver use cyclic dma ?

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Lars-Peter Clausen]

On 06/22/2015 04:35 AM, Raymond Yau wrote:
>
>  >
>  > DMA_RESIDUE_GRANULARITY_BURST means it can report the position with a
> granularity of a few samples. Typically half the audio FIFO size.
>  >
>  >
>
> How many soc driver/platform dma engine support DMA_RESIDUE_GRANULARITY_BURST ?

Not sure, maybe half of them. But most of the time it is a software 
restriction rather than a hardware restriction and more and more drivers are 
supporting it.

>
> Are all soc audio driver use cyclic dma ?

I'm not sure I understand the question. All audio drivers use some kind of 
cyclic DMA. ASoC platforms which do not have a dedicated audio DMA typically 
use dmaengine for this, while others which have dedicated audio DMA do the 
DMA as part of the audio driver.

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

2015-6-22 下午2:43 於 "Lars-Peter Clausen" <lars@metafoo.de> 寫道：
>
> On 06/22/2015 04:35 AM, Raymond Yau wrote:
>>
>>
>>  >
>>  > DMA_RESIDUE_GRANULARITY_BURST means it can report the position with a
>> granularity of a few samples. Typically half the audio FIFO size.
>>  >
>>  >
>>
>> How many soc driver/platform dma engine support
DMA_RESIDUE_GRANULARITY_BURST ?
>
>
> Not sure, maybe half of them. But most of the time it is a software
restriction rather than a hardware restriction and more and more drivers
are supporting it.

https://bugs.freedesktop.org/attachment.cgi?id=107650

snd_rpi_hifiberry_amp

granularity seem 4 frames most of the time but sometime there is a large
delay between 3584 and 3988 ,seem cannot reach 4096

Available: 3580, loop iteration: 420
Available: 3584, loop iteration: 421
Available: 3988, loop iteration: 422
Available: 3996, loop iteration: 423
Available: 4004, loop iteration: 424
Available: 4012, loop iteration: 425

Are the pointer callback really use value read from hardware register or
value calculated from clock ?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Clemens Ladisch]

Lars-Peter Clausen wrote:
> On 06/22/2015 04:35 AM, Raymond Yau wrote:
>> Are all soc audio driver use cyclic dma ?
>
> I'm not sure I understand the question. All audio drivers use some
> kind of cyclic DMA.

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.


Regards,
Clemens

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

> >> Are all soc audio driver use cyclic dma ?
> >
> > I'm not sure I understand the question. All audio drivers use some
> > kind of cyclic DMA.
>
> 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

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Alexander E. Patrakov]

22.06.2015 16:54, Raymond Yau wrote:
>>>> Are all soc audio driver use cyclic dma ?
>>>
>>> I'm not sure I understand the question. All audio drivers use some
>>> kind of cyclic DMA.
>>
>> 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

-- 
Alexander E. Patrakov

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>>>
>>> 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

Do this mean .period_bytes_min of snd-usb-audio is incorrect since
.period_bytes_min should be at least size of urb/packet ?

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Alexander E. Patrakov]

22.06.2015 17:34, 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.

-- 
Alexander E. Patrakov

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>>
>>  >>>
>>  >>> 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) ?

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Alexander E. Patrakov]

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

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Takashi Sakamoto]

On jUN 22 2015 21:10, Alexander E. Patrakov wrote:
> 22.06.2015 16:54, Raymond Yau wrote:
>>>>> Are all soc audio driver use cyclic dma ?
>>>>
>>>> I'm not sure I understand the question. All audio drivers use some
>>>> kind of cyclic DMA.
>>>
>>> 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

No need at all for ALSA firewire drivers, because PCM frames which is
not transferred are still rewindable.

Current ALSA firewire stack implementation, 16 packets are queued in one
callback from software interrupt context. In IEEE 1394 bus, 8,000
packets are transmitted per second. Therefore, one callback processes
PCM frames around 2 msec.
(Actually, in IEC 61883-6, two ways to transfer PCM frames in
these packets, thus one callback cannot processes PCM frames 'just' 2 msec.)

Let's consider about actual time, for example, in my system:
 * Software interrupt interval takes 1.986-2.015msec
 * The processing of one callback takes 0.024-0.026msec

(Intel DH77DF, Core i3-2120T, 4GB RAM, VT6315 as 1394 OHCI controller)

During processing one callback, pcm frames are copied to packet buffer.
The 'hw_ptr' is updated every time the number of copied pcm
frames is across period boundary. Therefore, the 'hw_ptr' suddenly jumps
by one period. This is a reason to use 'SNDRV_PCM_INFO_BLOCK_TRANSFER'.

While, snd-firewire-lib has internal representation to count the number
of transferred PCM frames. The 'struct snd_pcm_ops.pointer()' returns
the counter in the representation. This counter is updated during the
callback processing, while it's not updated between the callback.
Therefore, the counter changes during 0.024-0.026msec and calm
during 1.986-2.015msec. In short, the counter doesn't move continuously.
Roughly, this may be observed as the returned value of 'struct
snd_pcm_ops.pointer()' changes every 1.986-2.015msec. This
is a reason to use 'SNDRV_PCM_INFO_BATCH'.

(I think we use these two flags as the same way as Lars explained:
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/093750.html)

(In my understanding, 'SNDRV_PCM_INFO_BATCH' means that 'struct
snd_pcm_ops.pointer()' returns correct value in PCM period/buffer but
the value doesn't change constantly against actual time frame.
Therefore, several periods must be included in the buffer.)

Well, here, I describe two aspects; one is for period size and
across-boundary, another is for rewindability.

* period size and across-boundary:
All of ALSA firewire drivers has a restriction that the minimum size of
period is equivalent to 5 msec. Our intension is that at least one
callback from software interrupt context occurs during processing PCM
frames equivalent to the size of period.
('5' msec is for safe. '3' msec may be OK, I think.)

* rewindability
During the 0.024-0.026msec, snd_pcm_rewindable() returns the value based
on currect pointer position in the internal representation in
snd-firewire-lib, while the value is immediately changed and the
retrieved value becomes old. During the 1.986-2.015msec,
snd_pcm_rewindable returns the fastened value because no PCM frames are
processed for transmission.


By the way, abour the packetization and PCM frame processing, I've
written a report:
https://github.com/takaswie/alsa-firewire-report

If you want to post your questions about ALSA firewire stack, please
read this report and consider about your issues before posting it,
Raymond. Of cource, I'm welcome to receive any questions or indications
about the content of my report.


Regards

Takashi Sakamoto

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>>  >>  >>> 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

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Alexander E. Patrakov]

15.06.2015 13:03, Lars-Peter Clausen wrote:
> On 06/12/2015 02:29 PM, Arun Raghavan wrote:
>> So I guess the first thing that would be nice to have is a clear
>> meaning of these two flags. With this done, we could potentially get
>> to the API to report the transfer size from the driver.
>
> Yeah, the meaning of those flags is somewhat fuzzy and may have changed
> over time as well. Here is my understanding of the flags, might not
> necessarily be 100% correct.
>
> SNDRV_PCM_INFO_BLOCK_TRANSFER means that the data is copied from the
> user accessible buffer in blocks of one period. Typically these kinds of
> devices have some dedicated audio memory that is not accessible via
> normal memory access and a DMA is setup to copy data from main memory to
> the dedicated memory. This DMA transfers the data from the main memory
> to the dedicated memory in chunks of period size. But otherwise the
> controller might still be capable of reporting a accurate pointer
> position down to the sample/frame level.
>
> So SNDRV_PCM_INFO_BLOCK_TRANSFER is mainly important for rewind handling
> and devices with that flag set might need additional headroom since the
> data up to one period after the pointer position has already been copied
> to the dedicated memory and hence can no longer be overwritten.
>
> 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. Typically this means a period sized granularity, but there
> are some other cases as well.

I have tried to convert this text into something that can be added to 
the doxygen documentation in alsa-lib, but failed to verify the text. 
Here is why.

In kernel sources, sound/pci/hda/hda_controller.c mentions 
SNDRV_PCM_INFO_BLOCK_TRANSFER. However, sub-period rewinds work fine on 
this driver, and the avail granularity is something like 64 bytes. So, 
either the description is wrong (i.e., "large blocks, possibly up to one 
period size, but 64 bytes still counts as large" is actually meant - but 
that would be useless), or the flag is wrongly set in the driver.

-- 
Alexander E. Patrakov

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Clemens Ladisch]

Alexander E. Patrakov wrote:
> 15.06.2015 13:03, Lars-Peter Clausen wrote:
>> So SNDRV_PCM_INFO_BLOCK_TRANSFER is mainly important for rewind handling
>> and devices with that flag set might need additional headroom since the
>> data up to one period after the pointer position has already been copied
>> to the dedicated memory and hence can no longer be overwritten.
>
> In kernel sources, sound/pci/hda/hda_controller.c mentions
> SNDRV_PCM_INFO_BLOCK_TRANSFER. However, sub-period rewinds work fine
> on this driver, and the avail granularity is something like 64 bytes.

HDA is a very typical PCI controller; if this flag were correct here,
pretty much _every_ driver would need it.

Some (older) HDA controllers have problems with position reporting
(with workarounds in the drivers), but those problems are with the
timing, not with the granularity.

As far as I can see, snd-hda-intel should just drop this flag.


Regards,
Clemens

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Alexander E. Patrakov]

27.06.2015 22:15, Clemens Ladisch wrote:
> Alexander E. Patrakov wrote:
>> 15.06.2015 13:03, Lars-Peter Clausen wrote:
>>> So SNDRV_PCM_INFO_BLOCK_TRANSFER is mainly important for rewind handling
>>> and devices with that flag set might need additional headroom since the
>>> data up to one period after the pointer position has already been copied
>>> to the dedicated memory and hence can no longer be overwritten.
>>
>> In kernel sources, sound/pci/hda/hda_controller.c mentions
>> SNDRV_PCM_INFO_BLOCK_TRANSFER. However, sub-period rewinds work fine
>> on this driver, and the avail granularity is something like 64 bytes.
>
> HDA is a very typical PCI controller; if this flag were correct here,
> pretty much _every_ driver would need it.

Well, there are more PCI drivers with this flag than without it. So it 
looks like a "typical error".

aep@aep-haswell /usr/src/linux/sound $ grep -l 
SNDRV_PCM_INFO_BLOCK_TRANSFER `grep -rl SNDRV_PCM_INFO_MMAP_VALID pci` | 
wc -l
48
aep@aep-haswell /usr/src/linux/sound $ grep -L 
SNDRV_PCM_INFO_BLOCK_TRANSFER `grep -rl SNDRV_PCM_INFO_MMAP_VALID pci` | 
wc -l
15


I guess I should write a program that tests sub-period rewinds and post 
it to the list.

> Some (older) HDA controllers have problems with position reporting
> (with workarounds in the drivers), but those problems are with the
> timing, not with the granularity.
>
> As far as I can see, snd-hda-intel should just drop this flag.

-- 
Alexander E. Patrakov

Re: PulseAudio and SNDRV_PCM_INFO_BATCH

[Raymond Yau]

>>>>
>>>> So SNDRV_PCM_INFO_BLOCK_TRANSFER is mainly important for rewind
handling
>>>> and devices with that flag set might need additional headroom since the
>>>> data up to one period after the pointer position has already been
copied
>>>> to the dedicated memory and hence can no longer be overwritten.
>>>
>>>
>>> In kernel sources, sound/pci/hda/hda_controller.c mentions
>>> SNDRV_PCM_INFO_BLOCK_TRANSFER. However, sub-period rewinds work fine
>>> on this driver, and the avail granularity is something like 64 bytes.

This is hardware specific feature which is essential for timer based
scheduling.

Even snd-usb-audio use a default number of packets for larger period size,
it is still need to change to use small period size for lowest latency

snd-hda-intel also set has .periods_max=32 which force driver not to use
small period size when application use maximum buffer size , it still
cannot adjust latency dynamically

>>
>>
>> HDA is a very typical PCI controller; if this flag were correct here,
>> pretty much _every_ driver would need it.
>
>
> Well, there are more PCI drivers with this flag than without it. So it
looks like a "typical error".
>
> aep@aep-haswell /usr/src/linux/sound $ grep -l
SNDRV_PCM_INFO_BLOCK_TRANSFER `grep -rl SNDRV_PCM_INFO_MMAP_VALID pci` | wc
-l
> 48
> aep@aep-haswell /usr/src/linux/sound $ grep -L
SNDRV_PCM_INFO_BLOCK_TRANSFER `grep -rl SNDRV_PCM_INFO_MMAP_VALID pci` | wc
-l
> 15
>
>
> I guess I should write a program that tests sub-period rewinds and post
it to the list.

>
>
>> Some (older) HDA controllers have problems with position reporting
>> (with workarounds in the drivers), but those problems are with the
>> timing, not with the granularity.
>>
>> As far as I can see, snd-hda-intel should just drop this flag.
>
>

http://lxr.free-electrons.com/ident?i=SNDRV_PCM_INFO_BLOCK_TRANSFER

SNDRV_PCM_INFO_BLOCK_TRANSFER is not present in those ISA sound cards which
use io ports to transfer data

Why do alsa-time-test.c use

if (cap == 0)
      r = snd_pcm_sw_params_set_avail_min(pcm, swparams, 1);
    else
      r = snd_pcm_sw_params_set_avail_min(pcm, swparams, 0);
    assert(r == 0);

What is oss wakeup point ?

snd_pcm_sw_params_set_avail_min

This is similar to setting an OSS wakeup point. The valid values for 'val'
are determined by the specific hardware. Most PC sound cards can only
accept power of 2 frame counts (i.e. 512, 1024, 2048).

Why sw_params use hardhware specific value ?

Can this value set to grsnularity which is smaller than period size since
the function silently force avail_min not less than period size ?