Dear developers, I had posted a question to mailing-list before: http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-December/022822.html When I tried to load 'module-alsa-sink' with 'mmap=0 tsched=1' parameters, tsched(timer-based scheduling) becomes disabled by default. Currently, it seems tsched is allowed only mmap supported ALSA devices. But, I found able to use tsched with 'mmap=0' option. For instance, unix_write() function is for non-mmap driven function that was written and regarded to tsched mode together. Please refer below test patch for supporting tsched mode on non-mmap driven ALSA configuration. Thanks in advance, KimJeongYeon ========== diff -uNr ./a/alsa-sink.c ./b/alsa-sink.c --- ./a/alsa-sink.c 2014-12-11 21:41:13.680373375 +0900 +++ ./b/alsa-sink.c 2014-12-11 21:45:50.032371336 +0900 @@ -2210,11 +2210,6 @@ u->use_mmap = use_mmap = false; } - if (use_tsched && (!b || !d)) { - pa_log_info("Cannot enable timer-based scheduling, falling back to sound IRQ scheduling."); - u->use_tsched = use_tsched = false; - } - if (u->use_mmap) pa_log_info("Successfully enabled mmap() mode."); diff -uNr ./a/alsa-util.c ./b/alsa-util.c --- ./a/alsa-util.c 2014-12-11 21:41:13.680373375 +0900 +++ ./b/alsa-util.c 2014-12-11 21:46:46.228370922 +0900 @@ -240,9 +240,6 @@ goto finish; } - if (!_use_mmap) - _use_tsched = false; - if (!pa_alsa_pcm_is_hw(pcm_handle)) _use_tsched = false; ==========
PCM access type */ typedef enum _snd_pcm_access { /** mmap access with simple interleaved channels */ SND_PCM_ACCESS_MMAP_INTERLEAVED = 0, /** mmap access with simple non interleaved channels */ SND_PCM_ACCESS_MMAP_NONINTERLEAVED, /** mmap access with complex placement */ SND_PCM_ACCESS_MMAP_COMPLEX, /** snd_pcm_readi/snd_pcm_writei access */ SND_PCM_ACCESS_RW_INTERLEAVED, /** snd_pcm_readn/snd_pcm_writen access */ SND_PCM_ACCESS_RW_NONINTERLEAVED, SND_PCM_ACCESS_LAST = SND_PCM_ACCESS_RW_NONINTERLEAVED } snd_pcm_access_t; which access type do your sound card support ? aplay -D hw:0,0 --dump-hw-params any.wav
- if (!_use_mmap) - _use_tsched = false; - pulseaudio only support SND_PCM_ACCESS_MMAP_INTERLEAVED and SND_PCM_ACCESS_RW_INTERLEAVED it fallback to use SND_PCM_ACCESS_RW_INTERLEAVED when driver only support SND_PCM_ACCESS_MMAP_COMPLEX and SND_PCM_ACCESS_RW_INTERLEAVED since pulseaudio does not support SND_PCM_ACCESS_MMAP_COMPLEX
# cat /proc/asound/card0/pcm1p/sub0/hw_params cat hw_params access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 4096 buffer_size: 4096 Sorry my aplay couldn't recognize '--dump-hw-params', but my pulse running on SND_PCM_ACCESS_RW_INTERLEAVED mode. Thanks, KimJeongYeon
period_size: 4096 buffer_size: 4096 do your sound card really support one period per buffer ?
In case of my card with test patch, 'mmap=0 tsched=1' configured one period per buffer due to enabling tsched mode. Is this general scenario while use tsched mode? If I tried to disable tsched mode, it configured half of 4095 period x 2 periods automatically.
do your sound card work with aplay since aplay don't like period size == buffer size ? http://git.alsa-project.org/?p=alsa-utils.git;a=commitdiff;h=946078f8c4cefcd99b20c155c0d38a1e23058395;hp=65dde04e4efa13a955199dcba94a58997eb0ec20
Sorry for confusing, it was executed via paplay, (not a aplay) period_size: 4096 buffer_size: 4096 were shown when I run 'paplay test.wav'.
1) alsa-sink with non-mmap + enable tshced (applied test patch) # paplay test.wav & # cat /proc/asound/card0/pcm1p/sub0/hw_params access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 4096 buffer_size: 4096 2) alsa-sink with non-mmap + enable tshced but it became turned-off (original code) # paplay test.wav & # cat /proc/asound/card0/pcm1p/sub0/hw_params access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 2048 buffer_size: 4096
you have to provide pulseaudio log with and without your patch ? did you change any paraemeter in daemon.conf and default.pa ? do you mean that module-udev-detect missing parameter to change mmap ?
http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-October/022018.html for irq mode, default fragment is 4 and 25 ms fragment time do your driver 's hardware constraints periods_min = 1 periods_max =2
timer scheduling is disabled when http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa?id=826c8f69d34ef49e86fe0ab6c93c1ffba8916131 https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/soc/soc-generic-dmaengine-pcm.c?id=478028e088d6a94666d8a776be2cd2291faf3bbd https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/include/linux/dmaengine.h DMA_RESIDUE_GRANULARITY_BURST: 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). */ enum dma_residue_granularity { DMA_RESIDUE_GRANULARITY_DESCRIPTOR = 0, DMA_RESIDUE_GRANULARITY_SEGMENT = 1, DMA_RESIDUE_GRANULARITY_BURST = 2, };
it was disabled by this patch http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa-util.c?id=045c1d602dcba57868845ba3270510593c39480f + if (!_use_mmap) + _use_tsched = FALSE; + access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 48000 (48000/1) period_size: 4096 buffer_size: 4096 if your sound card support one period per buffer , do it support disable period wakeup ? http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/alsa?id=051d82133f0ae6a57bf66fd200bc8e3591a7d5ca
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/320.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.