Summary: | pulseaudio jack modules drop samples on low fragment sizes | ||
---|---|---|---|
Product: | PulseAudio | Reporter: | Michał Zegan <webczat_200> |
Component: | modules | Assignee: | pulseaudio-bugs |
Status: | RESOLVED MOVED | QA Contact: | pulseaudio-bugs |
Severity: | normal | ||
Priority: | medium | CC: | lennart |
Version: | unspecified | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Michał Zegan
2015-09-27 22:16:04 UTC
do you mean Jack is running with 2 periods of 256 frames ? this mean that pulseaudio should reject any client request latency lower than the jack server Raymond, let's not reiterate over the relationship between the sink's minimum wakeup period and the client latency. PulseAudio cannot reject this case, because it can also appear because of stream-moving in pavucontrol. Please see bug 66962 (wrongly closed as fixed, even though it is only worked around). The long-term plan in description there (about timer-based emulation) is spot on, and that suggestion has never been implemented. module-jack-sink only support fixed latency and does not support rewind although you may deduce the jack server use which alsa card since pulseaudio need to release that card to jackd pulseaudio still unable to change the hardware volume control of the sound card, any volume change was force to use software volume when the sink does not support rewind In this specific case it is 128 fragments and 2 periods. in case of 256, it works correctly, in case of 128 it drops samples. http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/jack/module-jack-sink.c?id=311654766207b3776e2618ae63ac35115db48bbd module-jack-sink/source: Set fixed latency correctly on creation http://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/src/modules/jack/module-jack-sink.c?id=29f064aa3d3a83e275361aad3f9e7efdc84b8ad0 do jack protcol really support rewind at such low latency jackd -p default is 1024 but you are using 128 or 256 what is the minimum period size when you using aplay without any underrun ? 32, 64, 128, 256, 512 aplay -Dhw:0,0 --period-size=32 --buffer-size=64 stereo.wav Had to use pasuspender, used this command without any changes just with my own file, and just changing period size, leaving buffer size intact, as I actually do not know how to change it, like I should double buffer size when doubling period size? if not, then 256 was the first... normal one jack_port_get_latency_range(u->port[0], JackPlaybackLatency, &r); n = r.max * pa_frame_size(&u->sink->sample_spec); pa_sink_set_fixed_latency(u->sink, pa_bytes_to_usec(n, &u->sink->sample_spec)); what is your jack 's latency and pulseaudio's fixed latency ? Actually in case of 2 periods/128 fragments, current latency is around 7 ms, fixed one is 5.33 ms (In reply to Michał Zegan from comment #7) > Had to use pasuspender, used this command without any changes just with my > own file, and just changing period size, leaving buffer size intact, as I > actually do not know how to change it, like I should double buffer size when > doubling period size? if not, then 256 was the first... normal one you have to stop jackd and pulseaudio 128 bytes is the minimum period bytes of snd-hda-intel , there are two choices if you get underrun when using aplay a) increase number of periods to 3, 4, 5, ..... b) increase period size and buffer size and keep the number of periods at 2 http://jackaudio.org/files/docs/html/group__LatencyFunctions.html you have to ask the author why pulseaudio only has JackPlaybackLatency but no JackCaptureLatency (In reply to Alexander E. Patrakov from comment #2) > Raymond, let's not reiterate over the relationship between the sink's > minimum wakeup period and the client latency. PulseAudio cannot reject this > case, because it can also appear because of stream-moving in pavucontrol. > Please see bug 66962 (wrongly closed as fixed, even though it is only worked > around). The long-term plan in description there (about timer-based > emulation) is spot on, and that suggestion has never been implemented. http://jackaudio.org/files/docs/html/index.html calling jack_client_open() to connect to the JACK server. registering "ports" to enable data to be moved to and from your application. registering a "process callback" which will be called at the right time by the JACK server. telling JACK that your application is ready to start processing data. it is JACK server call jack_process callback and pulseaudio server have to supply enough frames Well, I actually did not run jackd, and pulseaudio was suspended, I depend on speech for usage of the computer because I am blind, so turning pa completely off is not an option. Suspending it allowed access to hw0,. Hello! After few years it is, I have tried testing aplay directly on sound card again. When ran on sysdefault pcm, minimum possible is buffer size 512, period size 256 (does that means two periods?). 128/2 does xrun. However: running on pcm hw, i can go down to 64 period size and 128 buffer size and it plays correctly. It starts heavily underrunning below that, when using buffer size 64 and period size 32. -- 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/158. |
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.