* PulseAudio and SNDRV_PCM_INFO_BATCH @ 2015-06-12 12:29 Arun Raghavan 2015-06-12 12:32 ` Arun Raghavan 2015-06-15 8:03 ` Lars-Peter Clausen 0 siblings, 2 replies; 39+ messages in thread From: Arun Raghavan @ 2015-06-12 12:29 UTC (permalink / raw) To: alsa-devel Cc: Takashi Iwai, Tanu Kaskinen, Lars-Peter Clausen, clemens, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-12 12:29 PulseAudio and SNDRV_PCM_INFO_BATCH Arun Raghavan @ 2015-06-12 12:32 ` Arun Raghavan 2015-06-12 13:43 ` Alexander E. Patrakov 2015-06-15 3:42 ` Raymond Yau 2015-06-15 8:03 ` Lars-Peter Clausen 1 sibling, 2 replies; 39+ messages in thread From: Arun Raghavan @ 2015-06-12 12:32 UTC (permalink / raw) To: alsa-devel Cc: Takashi Iwai, Tanu Kaskinen, Lars-Peter Clausen, clemens, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-12 12:32 ` Arun Raghavan @ 2015-06-12 13:43 ` Alexander E. Patrakov 2015-06-12 13:57 ` Alexander E. Patrakov 2015-06-17 3:04 ` Raymond Yau 2015-06-15 3:42 ` Raymond Yau 1 sibling, 2 replies; 39+ messages in thread From: Alexander E. Patrakov @ 2015-06-12 13:43 UTC (permalink / raw) To: Arun Raghavan, alsa-devel Cc: Takashi Iwai, Tanu Kaskinen, Lars-Peter Clausen, clemens, David Henningsson [-- 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 --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-12 13:43 ` Alexander E. Patrakov @ 2015-06-12 13:57 ` Alexander E. Patrakov 2015-06-17 3:04 ` Raymond Yau 1 sibling, 0 replies; 39+ messages in thread From: Alexander E. Patrakov @ 2015-06-12 13:57 UTC (permalink / raw) To: Arun Raghavan, alsa-devel Cc: Takashi Iwai, Tanu Kaskinen, Lars-Peter Clausen, clemens, David Henningsson [-- 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 --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-12 13:43 ` Alexander E. Patrakov 2015-06-12 13:57 ` Alexander E. Patrakov @ 2015-06-17 3:04 ` Raymond Yau 2015-06-17 3:38 ` Alexander E. Patrakov 1 sibling, 1 reply; 39+ messages in thread From: Raymond Yau @ 2015-06-17 3:04 UTC (permalink / raw) To: Alexander E. Patrakov Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson >>> 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 ? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-17 3:04 ` Raymond Yau @ 2015-06-17 3:38 ` Alexander E. Patrakov 0 siblings, 0 replies; 39+ messages in thread From: Alexander E. Patrakov @ 2015-06-17 3:38 UTC (permalink / raw) To: Raymond Yau Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-12 12:32 ` Arun Raghavan 2015-06-12 13:43 ` Alexander E. Patrakov @ 2015-06-15 3:42 ` Raymond Yau 1 sibling, 0 replies; 39+ messages in thread From: Raymond Yau @ 2015-06-15 3:42 UTC (permalink / raw) To: Arun Raghavan Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, clemens, Tanu Kaskinen, David Henningsson > > 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 ? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-12 12:29 PulseAudio and SNDRV_PCM_INFO_BATCH Arun Raghavan 2015-06-12 12:32 ` Arun Raghavan @ 2015-06-15 8:03 ` Lars-Peter Clausen 2015-06-15 11:39 ` Raymond Yau 2015-06-27 15:28 ` Alexander E. Patrakov 1 sibling, 2 replies; 39+ messages in thread From: Lars-Peter Clausen @ 2015-06-15 8:03 UTC (permalink / raw) To: Arun Raghavan, alsa-devel Cc: Takashi Iwai, Tanu Kaskinen, clemens, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-15 8:03 ` Lars-Peter Clausen @ 2015-06-15 11:39 ` Raymond Yau 2015-06-15 12:01 ` Lars-Peter Clausen 2015-06-27 15:28 ` Alexander E. Patrakov 1 sibling, 1 reply; 39+ messages in thread From: Raymond Yau @ 2015-06-15 11:39 UTC (permalink / raw) To: Lars-Peter Clausen Cc: ALSA Development Mailing List, Takashi Iwai, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson >> >> 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 ? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-15 11:39 ` Raymond Yau @ 2015-06-15 12:01 ` Lars-Peter Clausen 2015-06-15 13:34 ` Raymond Yau 0 siblings, 1 reply; 39+ messages in thread From: Lars-Peter Clausen @ 2015-06-15 12:01 UTC (permalink / raw) To: Raymond Yau Cc: ALSA Development Mailing List, Takashi Iwai, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-15 12:01 ` Lars-Peter Clausen @ 2015-06-15 13:34 ` Raymond Yau 2015-06-15 14:16 ` Lars-Peter Clausen 0 siblings, 1 reply; 39+ messages in thread From: Raymond Yau @ 2015-06-15 13:34 UTC (permalink / raw) To: Lars-Peter Clausen Cc: Tanu Kaskinen, Takashi Iwai, clemens, ALSA Development Mailing List, Arun Raghavan, David Henningsson >>>> >>>> >>>> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-15 13:34 ` Raymond Yau @ 2015-06-15 14:16 ` Lars-Peter Clausen 2015-06-16 2:33 ` Raymond Yau 2015-06-22 2:35 ` Raymond Yau 0 siblings, 2 replies; 39+ messages in thread From: Lars-Peter Clausen @ 2015-06-15 14:16 UTC (permalink / raw) To: Raymond Yau Cc: Tanu Kaskinen, Takashi Iwai, clemens, ALSA Development Mailing List, Arun Raghavan, David Henningsson 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-15 14:16 ` Lars-Peter Clausen @ 2015-06-16 2:33 ` Raymond Yau 2015-06-17 8:27 ` Lars-Peter Clausen 2015-06-22 2:35 ` Raymond Yau 1 sibling, 1 reply; 39+ messages in thread From: Raymond Yau @ 2015-06-16 2:33 UTC (permalink / raw) To: Lars-Peter Clausen Cc: ALSA Development Mailing List, Takashi Iwai, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson >> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-16 2:33 ` Raymond Yau @ 2015-06-17 8:27 ` Lars-Peter Clausen 2015-06-17 9:19 ` Takashi Iwai 0 siblings, 1 reply; 39+ messages in thread From: Lars-Peter Clausen @ 2015-06-17 8:27 UTC (permalink / raw) To: Raymond Yau Cc: ALSA Development Mailing List, Takashi Iwai, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-17 8:27 ` Lars-Peter Clausen @ 2015-06-17 9:19 ` Takashi Iwai 2015-06-17 15:09 ` David Henningsson 0 siblings, 1 reply; 39+ messages in thread From: Takashi Iwai @ 2015-06-17 9:19 UTC (permalink / raw) To: Lars-Peter Clausen Cc: ALSA Development Mailing List, clemens, Tanu Kaskinen, Arun Raghavan, Raymond Yau, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-17 9:19 ` Takashi Iwai @ 2015-06-17 15:09 ` David Henningsson 2015-06-17 16:48 ` Alexander E. Patrakov ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: David Henningsson @ 2015-06-17 15:09 UTC (permalink / raw) To: Takashi Iwai, Lars-Peter Clausen Cc: Raymond Yau, ALSA Development Mailing List, clemens, Tanu Kaskinen, Arun Raghavan 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-17 15:09 ` David Henningsson @ 2015-06-17 16:48 ` Alexander E. Patrakov 2015-06-18 3:15 ` Raymond Yau 2015-06-19 1:17 ` Raymond Yau 2015-06-19 11:32 ` Takashi Iwai 2 siblings, 1 reply; 39+ messages in thread From: Alexander E. Patrakov @ 2015-06-17 16:48 UTC (permalink / raw) To: David Henningsson, Takashi Iwai, Lars-Peter Clausen Cc: Raymond Yau, ALSA Development Mailing List, clemens, Tanu Kaskinen, Arun Raghavan [-- 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(¶ms); 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 --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-17 16:48 ` Alexander E. Patrakov @ 2015-06-18 3:15 ` Raymond Yau 2015-06-19 11:19 ` Alexander E. Patrakov 0 siblings, 1 reply; 39+ messages in thread From: Raymond Yau @ 2015-06-18 3:15 UTC (permalink / raw) To: Alexander E. Patrakov Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson >>> >>> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-18 3:15 ` Raymond Yau @ 2015-06-19 11:19 ` Alexander E. Patrakov 0 siblings, 0 replies; 39+ messages in thread From: Alexander E. Patrakov @ 2015-06-19 11:19 UTC (permalink / raw) To: Raymond Yau Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson [-- 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(¶ms); 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 --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-17 15:09 ` David Henningsson 2015-06-17 16:48 ` Alexander E. Patrakov @ 2015-06-19 1:17 ` Raymond Yau 2015-06-19 11:32 ` Takashi Iwai 2 siblings, 0 replies; 39+ messages in thread From: Raymond Yau @ 2015-06-19 1:17 UTC (permalink / raw) To: David Henningsson Cc: Tanu Kaskinen, Lars-Peter Clausen, Takashi Iwai, clemens, ALSA Development Mailing List, Arun Raghavan > 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% ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-17 15:09 ` David Henningsson 2015-06-17 16:48 ` Alexander E. Patrakov 2015-06-19 1:17 ` Raymond Yau @ 2015-06-19 11:32 ` Takashi Iwai 2015-06-20 3:24 ` Raymond Yau 2015-06-20 6:17 ` Raymond Yau 2 siblings, 2 replies; 39+ messages in thread From: Takashi Iwai @ 2015-06-19 11:32 UTC (permalink / raw) To: David Henningsson Cc: ALSA Development Mailing List, Lars-Peter Clausen, clemens, Tanu Kaskinen, Arun Raghavan, Raymond Yau 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-19 11:32 ` Takashi Iwai @ 2015-06-20 3:24 ` Raymond Yau 2015-06-20 6:17 ` Raymond Yau 1 sibling, 0 replies; 39+ messages in thread From: Raymond Yau @ 2015-06-20 3:24 UTC (permalink / raw) To: Takashi Iwai, o-takashi Cc: ALSA Development Mailing List, Lars-Peter Clausen, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson > > > 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 ? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-19 11:32 ` Takashi Iwai 2015-06-20 3:24 ` Raymond Yau @ 2015-06-20 6:17 ` Raymond Yau 1 sibling, 0 replies; 39+ messages in thread From: Raymond Yau @ 2015-06-20 6:17 UTC (permalink / raw) To: Takashi Iwai Cc: ALSA Development Mailing List, Lars-Peter Clausen, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson > > 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 ? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-15 14:16 ` Lars-Peter Clausen 2015-06-16 2:33 ` Raymond Yau @ 2015-06-22 2:35 ` Raymond Yau 2015-06-22 6:43 ` Lars-Peter Clausen 1 sibling, 1 reply; 39+ messages in thread From: Raymond Yau @ 2015-06-22 2:35 UTC (permalink / raw) To: Lars-Peter Clausen Cc: ALSA Development Mailing List, Takashi Iwai, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson > > 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 ? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-22 2:35 ` Raymond Yau @ 2015-06-22 6:43 ` Lars-Peter Clausen 2015-06-22 7:49 ` Raymond Yau 2015-06-22 9:41 ` Clemens Ladisch 0 siblings, 2 replies; 39+ messages in thread From: Lars-Peter Clausen @ 2015-06-22 6:43 UTC (permalink / raw) To: Raymond Yau Cc: ALSA Development Mailing List, Takashi Iwai, clemens, Tanu Kaskinen, Arun Raghavan, David Henningsson 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-22 6:43 ` Lars-Peter Clausen @ 2015-06-22 7:49 ` Raymond Yau 2015-06-22 9:41 ` Clemens Ladisch 1 sibling, 0 replies; 39+ messages in thread From: Raymond Yau @ 2015-06-22 7:49 UTC (permalink / raw) To: Lars-Peter Clausen Cc: Tanu Kaskinen, Takashi Iwai, clemens, ALSA Development Mailing List, Arun Raghavan, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-22 6:43 ` Lars-Peter Clausen 2015-06-22 7:49 ` Raymond Yau @ 2015-06-22 9:41 ` Clemens Ladisch 2015-06-22 11:54 ` Raymond Yau 1 sibling, 1 reply; 39+ messages in thread From: Clemens Ladisch @ 2015-06-22 9:41 UTC (permalink / raw) To: Lars-Peter Clausen, Raymond Yau Cc: Takashi Iwai, ALSA Development Mailing List, Tanu Kaskinen, Arun Raghavan, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-22 9:41 ` Clemens Ladisch @ 2015-06-22 11:54 ` Raymond Yau 2015-06-22 12:10 ` Alexander E. Patrakov 0 siblings, 1 reply; 39+ messages in thread From: Raymond Yau @ 2015-06-22 11:54 UTC (permalink / raw) To: Clemens Ladisch Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, Tanu Kaskinen, Arun Raghavan, David Henningsson > >> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-22 11:54 ` Raymond Yau @ 2015-06-22 12:10 ` Alexander E. Patrakov 2015-06-22 12:34 ` Raymond Yau 2015-06-22 22:52 ` Takashi Sakamoto 0 siblings, 2 replies; 39+ messages in thread From: Alexander E. Patrakov @ 2015-06-22 12:10 UTC (permalink / raw) To: Raymond Yau, Clemens Ladisch Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, Tanu Kaskinen, Arun Raghavan, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-22 12:10 ` Alexander E. Patrakov @ 2015-06-22 12:34 ` Raymond Yau 2015-06-22 12:49 ` Alexander E. Patrakov 2015-06-22 22:52 ` Takashi Sakamoto 1 sibling, 1 reply; 39+ messages in thread From: Raymond Yau @ 2015-06-22 12:34 UTC (permalink / raw) To: Alexander E. Patrakov Cc: Tanu Kaskinen, Lars-Peter Clausen, Takashi Iwai, Clemens Ladisch, ALSA Development Mailing List, Arun Raghavan, David Henningsson >>> >>> 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 ? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-22 12:34 ` Raymond Yau @ 2015-06-22 12:49 ` Alexander E. Patrakov 2015-06-22 15:50 ` Raymond Yau 0 siblings, 1 reply; 39+ messages in thread From: Alexander E. Patrakov @ 2015-06-22 12:49 UTC (permalink / raw) To: Raymond Yau Cc: Tanu Kaskinen, Lars-Peter Clausen, Takashi Iwai, Clemens Ladisch, ALSA Development Mailing List, Arun Raghavan, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-22 12:49 ` Alexander E. Patrakov @ 2015-06-22 15:50 ` Raymond Yau 2015-06-22 16:28 ` Alexander E. Patrakov 0 siblings, 1 reply; 39+ messages in thread From: Raymond Yau @ 2015-06-22 15:50 UTC (permalink / raw) To: Alexander E. Patrakov Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, Clemens Ladisch, Tanu Kaskinen, Arun Raghavan, David Henningsson >> >> >>> >> >>> 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) ? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-22 15:50 ` Raymond Yau @ 2015-06-22 16:28 ` Alexander E. Patrakov 2015-06-24 5:51 ` Raymond Yau 0 siblings, 1 reply; 39+ messages in thread From: Alexander E. Patrakov @ 2015-06-22 16:28 UTC (permalink / raw) To: Raymond Yau Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, Clemens Ladisch, Tanu Kaskinen, Arun Raghavan, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-22 16:28 ` Alexander E. Patrakov @ 2015-06-24 5:51 ` Raymond Yau 0 siblings, 0 replies; 39+ messages in thread From: Raymond Yau @ 2015-06-24 5:51 UTC (permalink / raw) To: Alexander E. Patrakov, adam Cc: Tanu Kaskinen, Lars-Peter Clausen, Takashi Iwai, Clemens Ladisch, ALSA Development Mailing List, Arun Raghavan, David Henningsson >> >> >>> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-22 12:10 ` Alexander E. Patrakov 2015-06-22 12:34 ` Raymond Yau @ 2015-06-22 22:52 ` Takashi Sakamoto 1 sibling, 0 replies; 39+ messages in thread From: Takashi Sakamoto @ 2015-06-22 22:52 UTC (permalink / raw) To: Alexander E. Patrakov, Raymond Yau, Clemens Ladisch Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, Tanu Kaskinen, Arun Raghavan, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-15 8:03 ` Lars-Peter Clausen 2015-06-15 11:39 ` Raymond Yau @ 2015-06-27 15:28 ` Alexander E. Patrakov 2015-06-27 17:15 ` Clemens Ladisch 1 sibling, 1 reply; 39+ messages in thread From: Alexander E. Patrakov @ 2015-06-27 15:28 UTC (permalink / raw) To: Lars-Peter Clausen, Arun Raghavan, alsa-devel Cc: Takashi Iwai, Tanu Kaskinen, clemens, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-27 15:28 ` Alexander E. Patrakov @ 2015-06-27 17:15 ` Clemens Ladisch 2015-06-27 17:58 ` Alexander E. Patrakov 0 siblings, 1 reply; 39+ messages in thread From: Clemens Ladisch @ 2015-06-27 17:15 UTC (permalink / raw) To: Alexander E. Patrakov, Lars-Peter Clausen, Arun Raghavan, alsa-devel Cc: Takashi Iwai, Tanu Kaskinen, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-27 17:15 ` Clemens Ladisch @ 2015-06-27 17:58 ` Alexander E. Patrakov 2015-06-28 2:09 ` Raymond Yau 0 siblings, 1 reply; 39+ messages in thread From: Alexander E. Patrakov @ 2015-06-27 17:58 UTC (permalink / raw) To: Clemens Ladisch, Lars-Peter Clausen, Arun Raghavan, alsa-devel Cc: Takashi Iwai, Tanu Kaskinen, David Henningsson 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: PulseAudio and SNDRV_PCM_INFO_BATCH 2015-06-27 17:58 ` Alexander E. Patrakov @ 2015-06-28 2:09 ` Raymond Yau 0 siblings, 0 replies; 39+ messages in thread From: Raymond Yau @ 2015-06-28 2:09 UTC (permalink / raw) To: Alexander E. Patrakov Cc: ALSA Development Mailing List, Lars-Peter Clausen, Takashi Iwai, Clemens Ladisch, Tanu Kaskinen, Arun Raghavan, David Henningsson >>>> >>>> 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 ? ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2015-06-28 2:09 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-06-12 12:29 PulseAudio and SNDRV_PCM_INFO_BATCH Arun Raghavan 2015-06-12 12:32 ` Arun Raghavan 2015-06-12 13:43 ` Alexander E. Patrakov 2015-06-12 13:57 ` Alexander E. Patrakov 2015-06-17 3:04 ` Raymond Yau 2015-06-17 3:38 ` Alexander E. Patrakov 2015-06-15 3:42 ` Raymond Yau 2015-06-15 8:03 ` Lars-Peter Clausen 2015-06-15 11:39 ` Raymond Yau 2015-06-15 12:01 ` Lars-Peter Clausen 2015-06-15 13:34 ` Raymond Yau 2015-06-15 14:16 ` Lars-Peter Clausen 2015-06-16 2:33 ` Raymond Yau 2015-06-17 8:27 ` Lars-Peter Clausen 2015-06-17 9:19 ` Takashi Iwai 2015-06-17 15:09 ` David Henningsson 2015-06-17 16:48 ` Alexander E. Patrakov 2015-06-18 3:15 ` Raymond Yau 2015-06-19 11:19 ` Alexander E. Patrakov 2015-06-19 1:17 ` Raymond Yau 2015-06-19 11:32 ` Takashi Iwai 2015-06-20 3:24 ` Raymond Yau 2015-06-20 6:17 ` Raymond Yau 2015-06-22 2:35 ` Raymond Yau 2015-06-22 6:43 ` Lars-Peter Clausen 2015-06-22 7:49 ` Raymond Yau 2015-06-22 9:41 ` Clemens Ladisch 2015-06-22 11:54 ` Raymond Yau 2015-06-22 12:10 ` Alexander E. Patrakov 2015-06-22 12:34 ` Raymond Yau 2015-06-22 12:49 ` Alexander E. Patrakov 2015-06-22 15:50 ` Raymond Yau 2015-06-22 16:28 ` Alexander E. Patrakov 2015-06-24 5:51 ` Raymond Yau 2015-06-22 22:52 ` Takashi Sakamoto 2015-06-27 15:28 ` Alexander E. Patrakov 2015-06-27 17:15 ` Clemens Ladisch 2015-06-27 17:58 ` Alexander E. Patrakov 2015-06-28 2:09 ` Raymond Yau
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.