Re: [pulseaudio-discuss] Pulseaudio and S/PDIF
On Fri, Mar 24, 2023 at 2:32 AM Jerry Geis wrote: > > >Don't bother. This is an issue common to 99% of USB webcams. Namely, > >those not listed explicitly in /usr/share/alsa/cards/USB-Audio.conf. > > >Both the analog and the fake S/PDIF microphones ultimately point to > >exactly the same ALSA hardware device. > > Alexandar - thanks > > But it seems if I dont "mute" the S/PDIF microphone - it get feedback ??? > If I mute it from the GUI and use the webcam all is fine. > If I unmute it back I get feedback. What do you mean by "feedback"? Are you saying that it somehow plays to your speakers, or that your words are captured twice, or that the other party complains during calls? As I said, these "analog" and "S/PDIF" microphones are in fact the same thing (both are mapped to hw:2), and, due to the mechanisms of profiles, only one can be active at a time, so it doesn't matter which one you use. To select the analog profile (which is mutually exclusive with the fake S/PDIF), run this command: pactl set-card-profile 2 input:analog-stereo But I am 100% sure that it won't help. To completely turn the webcam microphone off, run this command: pactl set-card-profile 2 off To filter out the sound of your speakers from the signal captured by the webcam, run this command: pactl load-module module-echo-cancel sink_master=alsa_output.pci-_00_1b.0. hdmi-stereo source_master=alsa_input.usb-046d_Logitech_Webcam_C930e_8E44BAAE-02.iec958-stereo channels=2 rate=48000 use_master_format=true (or source_master=alsa_input.usb-046d_Logitech_Webcam_C930e_8E44BAAE-02.analog-stereo if you switched the webcam to analog, but, again, this is meaningless) This will create a new sink and a new source that have "echo cancelled" in their names. Set them as default and move all applications to them. -- Alexander E. Patrakov
Re: [pulseaudio-discuss] Pulseaudio and S/PDIF
vered = "1" >> device.icon_name = "camera-web-usb" >> ports: >> iec958-stereo-input: Digital Input (S/PDIF) (priority 0, latency offset 0 >> usec, available: unknown) >> properties: >> >> active port: > > > This shows it: with "pacmd list-cards" > > input:analog-stereo: Analog Stereo Input (priority 65, available: unknown) > input:iec958-stereo: Digital Stereo (IEC958) Input (priority 55, available: > unknown) > > I want the analog to be active and want to MUTE this iec958 > > So there are TWO microphones presented on this card (webcam) or USB input > microphone. > I want to use the analog one and not the iec958. I get feedback with both > enabled. > I can mute it from GUI - but I need to be able to mute JUST the iec958 input > and not the analog from the command line. > > So seems the webcam presents two microphones- I need to mute one of them > S/PDIF from the command line > thanks > > Jerry > > > pacmd list-cards > 2 card(s) available. > index: 0 > name: > driver: > owner module: 7 > properties: > alsa.card = "1" > alsa.card_name = "Logitech Webcam C930e" > alsa.long_card_name = "Logitech Webcam C930e at usb-:00:14.0-2, high > speed" > alsa.driver_name = "snd_usb_audio" > device.bus_path = "pci-:00:14.0-usb-0:2:1.2" > sysfs.path = "/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.2/sound/card1" > udev.id = "usb-046d_Logitech_Webcam_C930e_8E44BAAE-02" > device.bus = "usb" > device.vendor.id = "046d" > device.vendor.name = "Logitech, Inc." > device.product.id = "0843" > device.product.name = "Webcam C930e" > device.serial = "046d_Logitech_Webcam_C930e_8E44BAAE" > device.form_factor = "webcam" > device.string = "1" > device.description = "Webcam C930e" > module-udev-detect.discovered = "1" > device.icon_name = "camera-web-usb" > profiles: > input:analog-stereo: Analog Stereo Input (priority 65, available: unknown) > input:iec958-stereo: Digital Stereo (IEC958) Input (priority 55, available: > unknown) > off: Off (priority 0, available: unknown) > active profile: > sources: > alsa_input.usb-046d_Logitech_Webcam_C930e_8E44BAAE-02.iec958-stereo/#2: > Webcam C930e Digital Stereo (IEC958) > ports: > analog-input-mic: Microphone (priority 8700, latency offset 0 usec, > available: unknown) > properties: > device.icon_name = "audio-input-microphone" > iec958-stereo-input: Digital Input (S/PDIF) (priority 0, latency offset 0 > usec, available: unknown) > properties: > > index: 1 > name: > driver: > owner module: 8 > properties: > alsa.card = "0" > alsa.card_name = "HDA Intel PCH" > alsa.long_card_name = "HDA Intel PCH at 0x89414000 irq 126" > alsa.driver_name = "snd_hda_intel" > device.bus_path = "pci-:00:1b.0" > sysfs.path = "/devices/pci:00/:00:1b.0/sound/card0" > device.bus = "pci" > device.vendor.id = "8086" > device.vendor.name = "Intel Corporation" > device.product.id = "2284" > device.product.name = "Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx > Series High Definition Audio Controller" > device.form_factor = "internal" > device.string = "0" > device.description = "Built-in Audio" > module-udev-detect.discovered = "1" > device.icon_name = "audio-card-pci" > profiles: > input:analog-stereo: Analog Stereo Input (priority 65, available: no) > output:analog-stereo: Analog Stereo Output (priority 6500, available: no) > output:analog-stereo+input:analog-stereo: Analog Stereo Duplex (priority > 6565, available: no) > output:analog-surround-40: Analog Surround 4.0 Output (priority 33968, > available: unknown) > output:analog-surround-40+input:analog-stereo: Analog Surround 4.0 Output + > Analog Stereo Input (priority 1265, available: unknown) > output:iec958-stereo: Digital Stereo (IEC958) Output (priority 38268, > available: unknown) > output:iec958-stereo+input:analog-stereo: Digital Stereo (IEC958) Output + > Analog Stereo Input (priority 5565, available: unknown) > output:hdmi-stereo: Digital Stereo (HDMI) Output (priority 38668, available: > unknown) > output:hdmi-stereo+input:analog-stereo: Digital Stereo (HDMI) Output + Analog > Stereo Input (priority 5965, available: unknown) > output:hdmi-surround: Digital Surround 5.1 (HDMI) Output (priority 33568, > available: unknown) > output:hdmi-surround+input:analog-stereo: Digital Surround 5.1 (HDMI) Output > + Analog Stereo Input (priority 865, available: unknown) > off: Off (priority 0, available: unknown) > active profile: > sinks: > alsa_output.pci-_00_1b.0.hdmi-stereo/#0: Built-in Audio Digital Stereo > (HDMI) > sources: > alsa_output.pci-_00_1b.0.hdmi-stereo.monitor/#1: Monitor of Built-in > Audio Digital Stereo (HDMI) > ports: > analog-input-mic: Microphone (priority 8700, latency offset 0 usec, > available: no) > properties: > device.icon_name = "audio-input-microphone" > analog-output-headphones: Headphones (priority 9900, latency offset 0 usec, > available: no) > properties: > device.icon_name = "audio-headphones" > analog-output: Analog Output (priority 9900, latency offset 0 usec, > available: unknown) > properties: > > iec958-stereo-output: Digital Output (S/PDIF) (priority 0, latency offset 0 > usec, available: unknown) > properties: > > hdmi-output-0: HDMI / DisplayPort (priority 5900, latency offset 0 usec, > available: yes) > properties: > device.icon_name = "video-display" > device.product.name = "SAMSUNG" Don't bother. This is an issue common to 99% of USB webcams. Namely, those not listed explicitly in /usr/share/alsa/cards/USB-Audio.conf. Both the analog and the fake S/PDIF microphones ultimately point to exactly the same ALSA hardware device. -- Alexander E. Patrakov
Re: [pulseaudio-discuss] No audio output; same setup worked before
сб, 13 февр. 2021 г. в 18:47, Rich Shepard : > What puzzles me is that I have the AT2500 and Focusrite set up as before > when I recorded slide shows using vokoscreenNG. My test using vokoscreenNG > and my webcam produced a file that ffprobe confirmed has both video and > audio streams, but no audio came from the speakers (which do work). > > More testing today. Thanks for the lesson about ALSA and PA and the > suggestion to check mic response in the Recording tab. Now that you mention vokoscreenNG... there was a bugfix release, 3.0.7, which mentions in its changelog that it fixes detection of recording devices. It was caused by incompatibility of the old code with GStreamer 1.16.x. Could you please make sure that you have at least that version? -- Alexander E. Patrakov CV: http://u.pc.cd/wT8otalK ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Virtual audio cable - high cpu usage
чт, 4 февр. 2021 г. в 03:10, Renaud GHIA : > Thank you for the tip. > Now I am sure that resampling does not apply (see below). > But unfortunately pulseaudio always consumes 30% of one CPU core! > The reason is that you are using module-loopback. Due to a potential difference between the clocks on the null sink and on the real sound card (even though both report 44100 Hz), it always has to resample in order to correct for the clock skew. If you don't understand, here is an analogy: you have two mechanical watches. Even though both claim that their hour hand makes one full circle every 12 hours, in fact, if left unattended, they will diverge over time. There is no way to avoid that, except by moving to Jack or PipeWire which simply don't introduce a null sink with an independent clock. If you decide to stay on PulseAudio, you can tweak the resampling method. The default, speex-float-1, is light on the CPU resources and should produce no distortions detectable by human ear on typical speech and music. It does produce easily detectable distortions on specifically crafted signals. If you want to make sure that the resampler is transparent no matter what is thrown at it, use speex-float-5. There is no point in going higher than that. -- Alexander E. Patrakov CV: http://u.pc.cd/wT8otalK ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] RFC: loopback manager
сб, 25 мая 2019 г. в 18:38, Tanu Kaskinen : > > Hello, > > I nowadays use module-loopback on a daily basis, and I thought it would > be nice to provide a GUI (in pavucontrol) for configuring loopbacks. > For this I propose we create a new module: module-loopback-manager. The > purpose of that module is to provide a client interface for managing > loopbacks. Without such manager interface it's not possible to create > loopbacks that stay around after reboot. Well, one could add module- > loopback to default.pa, but that doesn't mesh well with dynamic > hardware, and that's not doable from pavucontrol anyway. The new module > would maintain a database of loopbacks, so that they can be recreated > after a reboot. > > The client interface would contain functionality for adding and > removing loopbacks, and changing the parameters of existing loopbacks. > > A loopback object would have the following attributes (to be shown in > "pactl list loopbacks"): > > Name: The identifier for the loopback. > > Description: A human-friendly description for UI labels. > > Source: The source name. Can also be unset, in which case the > loopback should follow the default source setting. > > Sink: The sink name. Can also be unset, in which case the loopback > should follow the default sink setting. > > Enabled: The user can temporarily disable a loopback without > removing it altogether. > > Running: A boolean that is true when the loopback is running, and > false when the loopback is stopped for whatever reason. The interface > should also provide a human-friendly string explaining why the loopback > is not running (the loopback could be disabled, the sink or source > might not be present at the moment, or the sink or source might be > suspended). > > Requested latency: The latency that has been requested by the user. > > Current latency: The current actual latency. Might be different > than the requested latency, because the requested latency may be too > low to work. > > Persistent: A boolean indicating whether the loopback will be > restored after restarting PulseAudio. My plan is that loopbacks that > are created through the manager interface are always persistent, and > non-persistent loopbacks are only for loopbacks that are created by > loading module-loopback. > > Source output index: When the loopback is running, it will have a > source output associated with it. > > Sink input index: When the loopback is running, it will have a sink > input associated with it. > > module-loopback index: When the loopback was created by loading > module-loopback, this is the module index. > > A maximum latency attribute could be added later, which would prevent > the loopback increasing the latency too much (at the cost of drop- > outs). > > The pactl interface could look like this: > > pactl loopback add [--description=] [--enabled=] > [--latency-msec=] > pactl loopback remove > pactl loopback set-description > pactl loopback set-source > pactl loopback set-sink > pactl loopback set-enabled /toggle > pactl loopback set-latency-msec > > Any thoughts? Would this kind of addition be welcome? If you think that > it's not worth having this feature, please say so, so that I don't > spend too much effort on this. I think it would be a useful exercise for you as a developer, even if there are very few users. At least, it is (AFAIK) the first attempt in PulseAudio to create something dynamically based on a policy stored in a persistent database. The experience gained through the exercise would likely be useful in other cases when one needs to deal with the "default.pa is too static and cannot configure hot-plugged things" problem. An obvious proposed addition to the API would be an ability to list persistent loopbacks, including those that refer to a source or a sink that doesn't exist at the moment. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] new module module-plugin-sink
пн, 20 мая 2019 г. в 15:35, Georg Chini : > > On 20.05.19 10:47, Alexander E. Patrakov wrote: > > пн, 20 мая 2019 г. в 13:17, Georg Chini : > >> Hi Alexander, Tanu, > >> > >> would it make sense to give filters some old data for preconditioning when > >> the filter should be rewound? Then the filter could simply be reset and the > >> preconditioning data run through the filter instead of doing a "real" > >> rewind. > >> The amount of data needed for preconditioning could be made configurable. > > The problem is that for IIR filter the needed amount of data is > > infinite. So - no. > > That's only true in theory. In practice, you never have an IIR filter > because you do not have infinite resolution. And in practice, it will > probably be sufficient to precondition the filter in many cases. > Surely the result will not be perfect, but may be good enough to > avoid audible artifacts. > > But if you think it does not make sense, I'll leave it as it is. In theory, you are right, except for a slowly-recovering automatic digital gain control filter (similar to the analog filters found in tape recorders from late 80s - they take about 30-60 seconds to adapt to unusually quiet sounds, and that still was a useful filter, not "chewing" the sounds exactly because of such slow recovery). In practice, I am also strongly against supporting any form of rewinds, for the following reasons (I admit that I am overly harsh here). 1. There is already some code, in the form of the LFE filter, that implements some filtering logic. Making it rewind-aware took 4 review iterations (which is too many), and there was a "how do I test" question. 2. Look at alsa-lib code. ALSA API supports rewinds. There is a lot of code that is supposed to handle rewinds. However, nothing works even in the "dmix" plugin which is not doing any history-related processing. 3. There was a submission of xrdp sink. It also had some (meaningless, because you can't unsend a packet) code written for rewind handling, and it was obviously not tested. To be fair, in the case (3) there was no good documentation what a sink should do, but case (2) comes from ALSA developers, so "appeal to authority" argument does apply here. In other words, I don't trust random people to write the rewind related code correctly (in fact, at this moment, I only trust David Henningsson), and I don't trust them even more to test it. In some sense, rewind-related code is similar to error handling: hard to get right and hard to test. And hard to fix (many people looked at the current situation with monitor sources, but they are still broken if there are rewinds). My personal opinion - we should not add such code to PulseAudio, and maybe even remove support except for the very easy cases. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] new module module-plugin-sink
пн, 20 мая 2019 г. в 13:17, Georg Chini : > > Hi Alexander, Tanu, > > would it make sense to give filters some old data for preconditioning when > the filter should be rewound? Then the filter could simply be reset and the > preconditioning data run through the filter instead of doing a "real" > rewind. > The amount of data needed for preconditioning could be made configurable. The problem is that for IIR filter the needed amount of data is infinite. So - no. An IIR-based replacement of module-virtual-surround will be sent to Georg privately to demonstrate the problem. Please note that it is not suitable for inclusion of PulseAudio. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] new module module-plugin-sink
вс, 5 мая 2019 г. в 22:58, Georg Chini : > > On 05.05.19 18:41, Alexander E. Patrakov wrote: > > вс, 5 мая 2019 г. в 01:41, Georg Chini : > >> On 04.05.19 20:54, Alexander E. Patrakov wrote: > >>> сб, 4 мая 2019 г. в 20:25, Georg Chini : > >>>> On 04.05.19 16:42, Alexander E. Patrakov wrote: > >>>>> сб, 4 мая 2019 г. в 16:17, Georg Chini : > >>>>>> Here is the new version of the header file, based on your feedback. > >>>>>> The main changes are: > >>>>>> > >>>>>> - The create_filter() function now receives the channel maps for input > >>>>>> and output. > >>>>>> - The create_filter() function receives a kill_filter() function and a > >>>>>> module pointer > >>>>>>which makes it possible for the filter to initiate unloading of > >>>>>> the > >>>>>> module if it > >>>>>>detects that it is no longer applicable. > >>>>>> - An output_changed() function was added which communicates current > >>>>>> sink > >>>>>> and port name to the filter, so that it can detect if the output > >>>>>> has > >>>>>> changed. > >>>>>> > >>>>>> Also I did a bit of cleanup and added a few more comments. Hope it > >>>>>> looks > >>>>>> better now. > >>>>> It definitely looks better. > >>>>> > >>>>> I am still confused about disable_rewind and max_latency. Let's > >>>>> suppose that someone wants to implement a rewindable filter. In this > >>>>> case, they need to keep history, because PulseAudio can ask the filter > >>>>> to rewind some samples. And, as it is not allowed to say "no", they > >>>>> must keep enough history to satisfy any possible rewind request. But > >>>>> some upper bound must exist. Do I understand correctly that > >>>>> max_latency serves as such upper bound? > >>>>> > >>>>> Regarding the non-rewindable filters, we do need to limit the latency, > >>>>> but I believe it is wrong for each individual filter to specify its > >>>>> own value for such limit. It should be a global policy (the same value > >>>>> for all non-rewindable sinks), and I don't see any reason for the > >>>>> filter to be able to influence it. > >>>>> > >>>>> Therefore, I believe these two fields can be replaced by one, > >>>>> max_rewind, which is the size of history, in samples, that the filter > >>>>> is willing to keep. Zero means a non-rewindable filter. > >>>>> > >>>> That sounds like a good suggestion. I would however think > >>>> that it is better if 0 means that the filter will rewind as far as > >>>> PA wants it to. There may be filters that are stateless (like the > >>>> trivial amplifier example). We could use -1 to disable rewinding. > >>> OK. > >>> > >>>> That would also mean to limit the latency to whatever the filter > >>>> can rewind, correct? I would use the maximum of max_rewind > >>>> and the default latency for non-rewindable filters as the > >>>> max_latency value then, because I don't think it makes sense > >>>> to set the maximum latency even smaller than for non-rewindable > >>>> filters. > >>> Makes sense. > >>> > >>>> What do you think is reasonable for non-rewindable filters? > >>>> 50 ms? > >>> There were different opinions on that matter. 50 ms is indeed in a > >>> range that I would agree to. > >>> > >> Just finished the next version. Does this look OK to you now? > > I think that the only significant difference is the addition of error > > codes. I cannot comment on them with any authority, but the majority > > do not seem applicable to filters. Probably we need some mechanism > > that allows arbitrary error strings to be logged? > > > The significant difference was the removal of max_latency and > the change of bool disable_rewind to int max_rewind. I need the > error codes for handling message replies, that's why I added > them. We should not need any other error reporting I think. Then OK on the "significant" difference, and no review on anything else. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] new module module-plugin-sink
вс, 5 мая 2019 г. в 01:41, Georg Chini : > > On 04.05.19 20:54, Alexander E. Patrakov wrote: > > сб, 4 мая 2019 г. в 20:25, Georg Chini : > >> On 04.05.19 16:42, Alexander E. Patrakov wrote: > >>> сб, 4 мая 2019 г. в 16:17, Georg Chini : > >>>> Here is the new version of the header file, based on your feedback. > >>>> The main changes are: > >>>> > >>>> - The create_filter() function now receives the channel maps for input > >>>> and output. > >>>> - The create_filter() function receives a kill_filter() function and a > >>>> module pointer > >>>> which makes it possible for the filter to initiate unloading of the > >>>> module if it > >>>> detects that it is no longer applicable. > >>>> - An output_changed() function was added which communicates current sink > >>>> and port name to the filter, so that it can detect if the output has > >>>> changed. > >>>> > >>>> Also I did a bit of cleanup and added a few more comments. Hope it looks > >>>> better now. > >>> It definitely looks better. > >>> > >>> I am still confused about disable_rewind and max_latency. Let's > >>> suppose that someone wants to implement a rewindable filter. In this > >>> case, they need to keep history, because PulseAudio can ask the filter > >>> to rewind some samples. And, as it is not allowed to say "no", they > >>> must keep enough history to satisfy any possible rewind request. But > >>> some upper bound must exist. Do I understand correctly that > >>> max_latency serves as such upper bound? > >>> > >>> Regarding the non-rewindable filters, we do need to limit the latency, > >>> but I believe it is wrong for each individual filter to specify its > >>> own value for such limit. It should be a global policy (the same value > >>> for all non-rewindable sinks), and I don't see any reason for the > >>> filter to be able to influence it. > >>> > >>> Therefore, I believe these two fields can be replaced by one, > >>> max_rewind, which is the size of history, in samples, that the filter > >>> is willing to keep. Zero means a non-rewindable filter. > >>> > >> That sounds like a good suggestion. I would however think > >> that it is better if 0 means that the filter will rewind as far as > >> PA wants it to. There may be filters that are stateless (like the > >> trivial amplifier example). We could use -1 to disable rewinding. > > OK. > > > >> That would also mean to limit the latency to whatever the filter > >> can rewind, correct? I would use the maximum of max_rewind > >> and the default latency for non-rewindable filters as the > >> max_latency value then, because I don't think it makes sense > >> to set the maximum latency even smaller than for non-rewindable > >> filters. > > Makes sense. > > > >> What do you think is reasonable for non-rewindable filters? > >> 50 ms? > > There were different opinions on that matter. 50 ms is indeed in a > > range that I would agree to. > > > Just finished the next version. Does this look OK to you now? I think that the only significant difference is the addition of error codes. I cannot comment on them with any authority, but the majority do not seem applicable to filters. Probably we need some mechanism that allows arbitrary error strings to be logged? -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] new module module-plugin-sink
сб, 4 мая 2019 г. в 20:25, Georg Chini : > > On 04.05.19 16:42, Alexander E. Patrakov wrote: > > сб, 4 мая 2019 г. в 16:17, Georg Chini : > >> Here is the new version of the header file, based on your feedback. > >> The main changes are: > >> > >> - The create_filter() function now receives the channel maps for input > >> and output. > >> - The create_filter() function receives a kill_filter() function and a > >> module pointer > >> which makes it possible for the filter to initiate unloading of the > >> module if it > >> detects that it is no longer applicable. > >> - An output_changed() function was added which communicates current sink > >> and port name to the filter, so that it can detect if the output has > >> changed. > >> > >> Also I did a bit of cleanup and added a few more comments. Hope it looks > >> better now. > > It definitely looks better. > > > > I am still confused about disable_rewind and max_latency. Let's > > suppose that someone wants to implement a rewindable filter. In this > > case, they need to keep history, because PulseAudio can ask the filter > > to rewind some samples. And, as it is not allowed to say "no", they > > must keep enough history to satisfy any possible rewind request. But > > some upper bound must exist. Do I understand correctly that > > max_latency serves as such upper bound? > > > > Regarding the non-rewindable filters, we do need to limit the latency, > > but I believe it is wrong for each individual filter to specify its > > own value for such limit. It should be a global policy (the same value > > for all non-rewindable sinks), and I don't see any reason for the > > filter to be able to influence it. > > > > Therefore, I believe these two fields can be replaced by one, > > max_rewind, which is the size of history, in samples, that the filter > > is willing to keep. Zero means a non-rewindable filter. > > > That sounds like a good suggestion. I would however think > that it is better if 0 means that the filter will rewind as far as > PA wants it to. There may be filters that are stateless (like the > trivial amplifier example). We could use -1 to disable rewinding. OK. > That would also mean to limit the latency to whatever the filter > can rewind, correct? I would use the maximum of max_rewind > and the default latency for non-rewindable filters as the > max_latency value then, because I don't think it makes sense > to set the maximum latency even smaller than for non-rewindable > filters. Makes sense. > What do you think is reasonable for non-rewindable filters? > 50 ms? There were different opinions on that matter. 50 ms is indeed in a range that I would agree to. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] new module module-plugin-sink
сб, 4 мая 2019 г. в 16:17, Georg Chini : > > Here is the new version of the header file, based on your feedback. > The main changes are: > > - The create_filter() function now receives the channel maps for input > and output. > - The create_filter() function receives a kill_filter() function and a > module pointer > which makes it possible for the filter to initiate unloading of the > module if it > detects that it is no longer applicable. > - An output_changed() function was added which communicates current sink >and port name to the filter, so that it can detect if the output has > changed. > > Also I did a bit of cleanup and added a few more comments. Hope it looks > better now. It definitely looks better. I am still confused about disable_rewind and max_latency. Let's suppose that someone wants to implement a rewindable filter. In this case, they need to keep history, because PulseAudio can ask the filter to rewind some samples. And, as it is not allowed to say "no", they must keep enough history to satisfy any possible rewind request. But some upper bound must exist. Do I understand correctly that max_latency serves as such upper bound? Regarding the non-rewindable filters, we do need to limit the latency, but I believe it is wrong for each individual filter to specify its own value for such limit. It should be a global policy (the same value for all non-rewindable sinks), and I don't see any reason for the filter to be able to influence it. Therefore, I believe these two fields can be replaced by one, max_rewind, which is the size of history, in samples, that the filter is willing to keep. Zero means a non-rewindable filter. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] new module module-plugin-sink
пт, 3 мая 2019 г. в 23:04, Georg Chini : > > On 03.05.19 16:32, Alexander E. Patrakov wrote: > > пт, 3 мая 2019 г. в 11:57, Georg Chini : > >> The channel layout of input/output > >> and the playback device is known to module-plugin-sink, so if > >> a filter needs it, it can be passed as parameter. No need to > >> have it in the interface. > > (I have also received your next email, ACK on the thought that the > > channel maps don't change on the fly). > > > > Having it (also with other properties like sink or port name) as a > > parameter is indeed a neat idea that solves a lot of problems. > Why would the filter code need the sink name? I understand > that it can be useful to know what kind of output you have, > but the sink name will not mean anything to the filter. The > plugins are compiled outside PA, similar to LADSPA plugins. Because filter sinks can, in theory, be moved, e.g. due to device hotplug or port status change, to a different master sink, to which they somehow know they are not applicable. > > However, we should still think about the boolean bypass parameter, how > > it is supposed to work. Is my understanding below correct? > > > > 1. The virtual surround filter gets created by PulseAudio for 6 input > > and 2 output channels and gets the input channel layout (5.1), output > > channel layout (stereo), and playback sink and port as parameters. > > 2. Some audio plays through it. > > 3. The user unplugs headphones, so that the output now goes through > > stereo speakers > > 4. Before sending the next chunk of audio, PulseAudio updates the > > filter parameters related to the sink port (a), and/or calls the > > set_port callback function (b). > > 5a. The filter notices the parameter change, processes the audio > > anyway, and sets the self-disable parameter to true. > > 6a. PulseAudio reads the audio and the self-disable parameter, throws > > away the processed audio and downmixes 5.1 to stereo by itself. > > 5b. set_port says "no" or updates the self-disable parameter, > > PulseAudio notices and downmixes 5.1 to stereo by itself. > > When the filter is in the chain, audio is processed by the filter. > Therefore, down mixing would have to be implemented in the > filter code. The next chunk after the parameter change would > need to be down mixed. > It is impossible to pass the original signal on to PA without > destroying and re-creating the sink input. (See also below). And that's exactly the problem with the filter sink model when the filter is applicable only in some cases that depend e.g. on what's connected. I have just tried to do this: 0. Make sure that both analog outputs and HDMI outputs are available as two sinks 1. Add a module-virtual-sink on top of analog stereo output, play some file in vlc through it. 2. Switch the analog sound card profile to 5.1 profile. AFAIK this could happen automatically on headphone unplugging on systems that have a separate headphone jack (mine doesn't, it only has line outputs, spdif, line input and microphone input on the back panel). Result: the virtual sink is still on top of the onboard analog sound card, and vlc is still playing through it. If this happens with a module-virtual-surround-sink, then it would convert the 5.1 sound from vlc to stereo according to an algorithm that is only valid for headphones (or, according to any other algorithm that it falls back to), and then PulseAudio would upmix this back to 5.1. Which is bad. The original 5.1 sound should have been passed through. Or, if it was not 5.1, the remixing should have happened from the original, not from the sound corrupted to stereo by the virtual-surround effect. I don't mind at all if you use the existing virtual surround sink code as an example to validate your API, but due to the above scenario, I think that it was a mistake to implement the virtual surround effect as a virtual sink. It should have been a special case in the remixer, just like the current LFE remixing code is now. I do understand that there are cases where the "external filter plugin sink" model is applicable. Just saying that virtual surround, if done properly, is not one of them. > > It would also be interesting to see what happens if unplugging the > > headphones causes the number of channels (of the channel layout in > > general) to change. Note that I don't have such setup, not even sure > > how it is handled currently. > > > The sink input that the filter uses will not change, regardless > what kind of sink the input is connected to. From the filter > perspective the channel counts and layouts are static. What does > PA usually do if the number of channels for a
Re: [pulseaudio-discuss] new module module-plugin-sink
пт, 3 мая 2019 г. в 11:57, Georg Chini : > The channel layout of input/output > and the playback device is known to module-plugin-sink, so if > a filter needs it, it can be passed as parameter. No need to > have it in the interface. (I have also received your next email, ACK on the thought that the channel maps don't change on the fly). Having it (also with other properties like sink or port name) as a parameter is indeed a neat idea that solves a lot of problems. However, we should still think about the boolean bypass parameter, how it is supposed to work. Is my understanding below correct? 1. The virtual surround filter gets created by PulseAudio for 6 input and 2 output channels and gets the input channel layout (5.1), output channel layout (stereo), and playback sink and port as parameters. 2. Some audio plays through it. 3. The user unplugs headphones, so that the output now goes through stereo speakers 4. Before sending the next chunk of audio, PulseAudio updates the filter parameters related to the sink port (a), and/or calls the set_port callback function (b). 5a. The filter notices the parameter change, processes the audio anyway, and sets the self-disable parameter to true. 6a. PulseAudio reads the audio and the self-disable parameter, throws away the processed audio and downmixes 5.1 to stereo by itself. 5b. set_port says "no" or updates the self-disable parameter, PulseAudio notices and downmixes 5.1 to stereo by itself. It would also be interesting to see what happens if unplugging the headphones causes the number of channels (of the channel layout in general) to change. Note that I don't have such setup, not even sure how it is handled currently. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] new module module-plugin-sink
пт, 3 мая 2019 г. в 09:31, Georg Chini : > > On 03.05.19 02:22, Alexander E. Patrakov wrote: > > чт, 2 мая 2019 г. в 23:45, Georg Chini : > >> Hi, > >> > >> I created a new module-plugin-sink and a small amplifier demo plugin > >> based on the attached header file. I did not (yet) drop max_latency, > >> disable_rewind and rewind_filter() because I am still waiting for more > >> feedback on the specification. I made it however more clear (using > >> Alexander's wording) that this should only be used if "real" rewinding > >> is possible. > > Thanks for that. > > > > However, the interface still thinks in terms of "number of channels", > > which is, in the general case, wrong. E.g., a "proper" > > module-virtual-surround-sink (not what we currently have) would sound > > differently if given the same samples in "5.1" and "5.1 (Side)" > > channel layouts. > I do not understand what you mean. How would you do it without > number of channels? You have to know how many input and > output channels are there, otherwise you can't process audio. I am saying that, if we are going to support filters with non-trivial interaction between channels, we would need to have a pa_channel_map somewhere. In your header, this structure is not mentioned at all. "5.1" and "5.1 (Side)" both have 6 channels. The hypothetical proper virtual surround plugin would need to know if its input is "5.1" or "5.1 (Side)", but, based on your interface, it can't. > > I wouldn't mind the number of channels, if we limit the interface to > > "true" filters that have the same number of input and output channels > > and don't care about the channel map. I.e., explicitly declare the > > virtual surround sink as out-of-scope. But then, what useful things > > are left in scope except the equalizer and maybe a dynamic range > > compressor? > Why would there be any reason to limit it to filters with > equal number of channels? Because that follows from the premise that the filter does not mix channels. And without channel layout information (i.e. given only the total number of inputs, but not even their order), it is impossible to mix channels meaningfully. > > Also, please make sure that, in the callbacks, the filter handle > > always comes as the first parameter. > No problem, but usually in pulseaudio the userdata pointer > comes last in callbacks. Ok, ok, the real idea was "be consistent" :) > > Regarding the virtual surround plugin, I actually have one more > > business argument why, if implemented properly (and not how it is done > > currently) it should be out of scope. The reason is that this plugin > > with publicly available HRIRs only applies to headphones. From a > > usability perspective, it should be switched off (or to a different > > filter, specifically crafted for each set of speakers and the > > listening room) when the audio is playing to something else than > > headphones. The proposed interface does not have (and likely should > > not have, because we want to keep it simple and stable) any place to > > express such policy. > Why would that be a problem? You can have a boolean bypass > parameter that switches off the filter when needed. Or even a > choice that switches between different HRIR files. Who would switch it (the virtual surround effect, I am not talking about other effects) off? The idea is that it is not the user (because with this particular effect it should really be automatic), and is not the filter itself (because it cannot know, based on your interface, that it is playing to speakers). So it has to be some third entity, with enough knowledge both about the filter and the PulseAudio notion of ports (to distinguish between speakers, headphones, and something unknown). And, given that entity, it does not really make sense to abstract the virtual surround implementation behind some common plugin interface, it has already leaked. As an example of prior art, please also consider the LFE channel remixer - it is not implemented as a virtual sink precisely for this reason. > > In other words, I am still very skeptical about the proposal, simply > > because we don't have enough filters to test the validity of the > > proposed interface. > > > I guess we need to start somewhere. Fair enough. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] new module module-plugin-sink
чт, 2 мая 2019 г. в 23:45, Georg Chini : > > Hi, > > I created a new module-plugin-sink and a small amplifier demo plugin > based on the attached header file. I did not (yet) drop max_latency, > disable_rewind and rewind_filter() because I am still waiting for more > feedback on the specification. I made it however more clear (using > Alexander's wording) that this should only be used if "real" rewinding > is possible. Thanks for that. However, the interface still thinks in terms of "number of channels", which is, in the general case, wrong. E.g., a "proper" module-virtual-surround-sink (not what we currently have) would sound differently if given the same samples in "5.1" and "5.1 (Side)" channel layouts. I wouldn't mind the number of channels, if we limit the interface to "true" filters that have the same number of input and output channels and don't care about the channel map. I.e., explicitly declare the virtual surround sink as out-of-scope. But then, what useful things are left in scope except the equalizer and maybe a dynamic range compressor? Also, please make sure that, in the callbacks, the filter handle always comes as the first parameter. Regarding the virtual surround plugin, I actually have one more business argument why, if implemented properly (and not how it is done currently) it should be out of scope. The reason is that this plugin with publicly available HRIRs only applies to headphones. From a usability perspective, it should be switched off (or to a different filter, specifically crafted for each set of speakers and the listening room) when the audio is playing to something else than headphones. The proposed interface does not have (and likely should not have, because we want to keep it simple and stable) any place to express such policy. In other words, I am still very skeptical about the proposal, simply because we don't have enough filters to test the validity of the proposed interface. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
вт, 30 апр. 2019 г. в 23:46, Georg Chini : > > On 30.04.19 19:23, Alexander E. Patrakov wrote: > >> /* If set, this function is called in thread context when an update > >> of the > >>* filter parameters is requested, may be NULL. The function must > >> replace > >>* the currently used parameter structure by the new structure and > >> return > >>* a pointer to the old structure so that it can be freed in the > >> main thread > >>* using parameter_free(). If the old structure can be re-used, the > >> function > >>* may return NULL. */ > >> void *(*update_filter_parameters)(void *parameters, void > >> *filter_handle); > > I don't think this is implementable. How are the parameters supposed > > to be initially allocated? > > > Why should this not be possible to implement? Meanwhile I have > it already implemented within the new virtual sink library and > I am using it for the virtual-surround-sink and also for > the ladspa-sink. Setting and querying parameters works > perfectly. For the virtual-surround-sink I allocate new memory > each time, while for the ladspa-sink I prepare a parameter set > in the main thread and copy it to the "real" parameter set > in the IO-thread. Please don't treat the FIR for module-virtual-surround-sink as a set of reconfigurable parameters. At least for now. Just hard-code the contents of http://stuff.salscheider-online.de/hrir_kemar.tar.gz or find a redistributable equivalent, preferably with more than 6 channels. > The initial parameter set must be allocated when the > filter is initialized. The parameter_set_all() function can be > used to do that or the filter_init() function could create a > default parameter set. OK, I retract the "not implementable" objection. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
вт, 30 апр. 2019 г. в 16:31, Georg Chini : > uint64_t min_latency; /* Minimum latency > allowed for the sink, 0 if unused */ > uint64_t max_latency; /* Maximum latency > allowed for the sink, 0 if unused */ Why would these fields be needed? > bool disable_rewind; /* True when rewinding is > disabled */ I'd say get rid of it either. It's too hard to implement rewinds correctly. Even in the simple cross-over filter that PulseAudio uses for LFE remixing, it took four tries to reach at something that doesn't produce clicks when the user e.g. changes the volume or otherwise triggers a rewind. Also, let's recollect the original purpose of the rewinds. They are, in the end, a way to save power. That is, to use a very long interval between wakeups if something non-interactive (like a music player) is doing its job, without the side effect of slow reaction to events like "new sink input wants to play something urgent". Please see my Linux Audio Conference presentation and video for more details: Paper: http://lac.linuxaudio.org/2015/papers/10.pdf Slides: http://lac.linuxaudio.org/2015/download/rewind-slides.pdf Video: http://lac.linuxaudio.org/2015/video.php?id=8 The main consideration here is that almost all filters are CPU-hungry enough to mask (i.e. make irrelevant) the savings obtained by dynamic latency and rewinds. So why give the filter implementer even an option to shoot themselves in the foot? > > /* Callback to reset the filter after rewind. May be NULL */ > void (*rewind_filter)(void *filter_handle, size_t amount); Don't say "reset" here. Reset is not a proper way to handle a rewind, users do notice the resulting clicks, see https://bugs.freedesktop.org/show_bug.cgi?id=50113 (note: this is NOT reported by me, there are real users who hear and care about this imperfection!) Please make it absolutely clear that the filter state must not be reset, but seamlessly restored to the specified point in the past (which is the filter's responsibility to keep). If one can't do that, they shouldn't say that they support rewinds. And yes, I understand that we have no filters (other than the trivial one) which handle this correctly. That's actually one of the reasons why I am so opposed to supporting rewindable filters. One more comment - the "void" return type means that the filter must be able to rewind itself no matter what, i.e. that failure is not possible and not allowed. Assuming that my hint to stop pretending to support rewinds gets ignored, I'd say that's a good thing. > > /* Callback to process a chunk of data by the filter. May be NULL */ > void (*process_chunk)(float *src, float *dst, unsigned count, void > *filter_handle); > > /* Callback to retrieve additional latency caused by the filter. > May be NULL */ > uint64_t (*get_extra_latency)(void *filter_handle); > > /* Initializes a new filter instance and returns a handle to it. */ > void *(*init_filter)(unsigned input_channels, unsigned > output_channels, unsigned sample_rate); > > /* Deletes filter instance. */ > void (*exit_filter)(void *filter_handle); > > /* If set, this function is called in thread context when an update > of the > * filter parameters is requested, may be NULL. The function must > replace > * the currently used parameter structure by the new structure and > return > * a pointer to the old structure so that it can be freed in the > main thread > * using parameter_free(). If the old structure can be re-used, the > function > * may return NULL. */ > void *(*update_filter_parameters)(void *parameters, void > *filter_handle); I don't think this is implementable. How are the parameters supposed to be initially allocated? -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
сб, 20 апр. 2019 г. в 15:20, Georg Chini : > > On 20.04.19 12:14, Alexander E. Patrakov wrote: > > [forgot to CC the list - sorry for any duplicates] > > > > сб, 20 апр. 2019 г. в 14:39, Georg Chini : > > > >> I think using malloc() when a parameter changes is not interfering > >> with real-time operation because the filter must be reset after > >> a parameter change anyway. > > The parameter changes allowed during the runtime are not expected to > > need a filter reset. In-place rebuild - yes, reset - no. The filtered > > audio should smoothly follow gradual changes of the filter parameters. > > Many LADSPA plugins actually implement internal smoothing of parameter > > value changes, or even internally keep two filter versions and > > interpolate between them, in order to avoid clicks, because such > > gradual changes are an expected thing in pro audio workflows. > > > Within PA, the filter must at least be rewound when a parameter changes. > Because rewinding is not part of the standard, the best we can do is to > reset the filter in that case by calling deactivate() and activate(). This is a bug in PA. Non-rewindable sinks are supported, actually exist (e.g. alsa-sink when the ALSA device is an ioplug, e.g. an AC3 encoder) and make sense if the latency is artificially limited to, say, 20-50 ms. So a LADSPA sink must just say "I can rewind zero samples", limit the latency, and ignore all rewind requests. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
[forgot to CC the list - sorry for any duplicates] сб, 20 апр. 2019 г. в 14:39, Georg Chini : > I think using malloc() when a parameter changes is not interfering > with real-time operation because the filter must be reset after > a parameter change anyway. The parameter changes allowed during the runtime are not expected to need a filter reset. In-place rebuild - yes, reset - no. The filtered audio should smoothly follow gradual changes of the filter parameters. Many LADSPA plugins actually implement internal smoothing of parameter value changes, or even internally keep two filter versions and interpolate between them, in order to avoid clicks, because such gradual changes are an expected thing in pro audio workflows. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
сб, 20 апр. 2019 г. в 05:54, Georg Chini : > But what you are basically saying is that the equalizer does > not hold what Andrea claims it can do and that it is only useful > as a 10-band equalizer. I wonder why her work was then > accepted as a master thesis. I don't know the Italian requirements for a master thesis. In Russia, rejections of this kind of thesis are rare: it's a time-boxed activity without a second chance to choose a topic (unlike the real scientific work), and rejections would make it a not-worth-it gamble in the students' eyes. And the same kind of number-of-pages stuffing (by including chapters on "considered but rejected" techniques) is common, I did it too. We do need a recheck from Italian experts not related to the government issued degrees. Probably on JACK mailing lists? And hopefully you now understand why I am inclined to reject even objectively-good scientific code submissions, if they are making something a part of PulseAudio: insufficient number of local experts that would have rejected bad submissions. OTOH, a plugin architecture that allows us to tap into the work by an existing pool of experts, without taking any responsibility, would be awesome. > >>> Besides, consumer electronic devices (TVs, HDMI receivers, Hi-Fi > >>> amplifiers) just do not have equalizers with a variable number of > >>> bands, for usability reasons. I don't see a reason for PulseAudio to > >>> be different. > >>> > >> You can't add sliders on the fly on a consumer electronic > >> device but you can do so in software. Why should we be guided > >> by a behavior that is governed by physical limits? If the algorithm > >> supports it, I see no reason why it should not be implemented. > >> (As said above naturally within some sane limits, you are right > >> that it would make no sense to have for example 50 bands.) > > Sliders in a consumer electronics device such as a TV are just virtual > > widgets on the screen, i.e. software, not physical knobs. Again, their > > number is fixed because of usable and "intuitive" UI. > I guess there are enough people who would wish for more > flexibility. > > > >> Surely you could go for several different plugins, but I do not > >> see the reason why the code should be duplicated a couple > >> of times. The goal is to have one plugin and not a collection. > >> I just don't like the idea that you have to duplicate things only > >> because of the limitation of the surrounding framework. > >> That's why I am looking for a way to dynamically adapt the > >> number of control ports or - which seems to be supported > >> by LV2 - use a control port that is an array. > > And my point is exactly that there is a reason, filter order, not > > related to any framework limitations, for different code for different > > number of bands. > > > >> Another example where an array would be useful as a control > >> port is the virtual-surround-sink. The HRIR data used by the filter > >> is an array of floats which could vary in size. > > I also disagree here. Yes, it can vary in size, but should not be > > treated as a control port at all. There is no way to usefully control > > it for a user, that's why. It should therefore be either hard-coded > > (as done in Windows) or loaded through a file. > > If you load it through a file like pulseaudio does, how do > you pass the values to the filter? Or should the plugin itself > load the file? The plugin itself should load the file. The fact that the file does not come with the plugin itself is a major bug that unfortunately exists for licensing reasons. I think we should find a free-enough data source for HRIR/HRTF and just hard-code the impulse responses, though. We can investigate reusing the data from CSound. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
сб, 20 апр. 2019 г. в 00:15, Georg Chini : > > On 19.04.19 18:23, Alexander E. Patrakov wrote: > > пт, 19 апр. 2019 г. в 14:13, Tanu Kaskinen : > >> If the plugin gets the number of bands during the > >> initialization, it can create the appropriate number of non-array > >> control ports. Interleaved audio ports aren't needed either, because > >> PulseAudio can do the deinterleaving before passing the audio to the > >> plugin (like module-ladspa-sink already does). If one's going to write > >> an LV2 plugin, it's best to use standard port types so that all hosts > >> will be able to use the plugin. > > In addition, I think that "if the plugin gets the number of bands [at > > runtime]" is a very big "if" for an IIR-based equalizer. So big that I > > would rather hard-code it, or treat equalizers with a different number > > of bands as completely different plugins. The reason is that the > > required slope of inter-band transition (i.e., effectively, the filter > > order) is a function of the width of each band. Implement a filter > > with a too-low order, and it won't be able to isolate (and thus > > control thegain of) a frequency band selectively enough. Implement a > > filter with a too-high order, and its frequency response will be too > > steppy. > > My understanding is that Andrea's equalizer algorithm supports > an arbitrary number of bands (certainly within some sane limits). > Please correct me if I am wrong. It supports arbitrary amount of bands, but not arbitrary filter order for a band. Just to reiterate, the whole filter is a cascade of some per-band filters of the same order. Each filter in the cascade is implemented, according to the dissertation, as a cut-and-boost filter, which is based on a band-pass filter, which is in turn based on a shelving Butterworth filter of order 2M. Hopefully I haven't missed any order-doubling here. I have not thoroughly checked whether the implementation actually follows the dissertation - this is complicated by the Italian language that I don't know, and cryptic variable names. The majority of the dissertation does contain formulas for an arbitrary even order (2M), but on page 41, it starts talking about filters of order 8 only. And, if I understand correctly, it doesn't match the code, which is hard-coded to implement only filters of order 4, and it is not only a matter of increasing M and M2 in the file, because then xn[i] must be set in eq_filter() for i >= 4. Another sign of this mismatch between the dissertation and the code is the different length of the "c" array - 10 in the code and 21 in algorithm 6.2 on page 43 (page numbers here are presented as printed at the bottom, not as displayed in PDF viewers' left pane). Because of the fixed order, there are indeed limits on the useful number of bands. E.g., given that the minimum and maximum supported gains in the band are -12 and 12 dB (at least this is what's mentioned in the dissertation), it means that the gain must increase by 24 dB between the centers of the neighboring bands. With the default 10-band filter, i.e. with one octave per band, this means that 24 dB per octave is the maximum supported slope, which is roughly right for a 4th order filter. In other words, more than 10 bands cannot be useful with 4th order filters and 24 dB of gain difference between the neighboring bands. I understand that it is odd to set the gain in two neighboring octaves to differ by that much. For a 5-band equalizer with the same gain limits, filters of 2nd order would be sufficient and preferable. Also, the order of the filter could be lowered if the gain limits are set lower. > > Besides, consumer electronic devices (TVs, HDMI receivers, Hi-Fi > > amplifiers) just do not have equalizers with a variable number of > > bands, for usability reasons. I don't see a reason for PulseAudio to > > be different. > > > You can't add sliders on the fly on a consumer electronic > device but you can do so in software. Why should we be guided > by a behavior that is governed by physical limits? If the algorithm > supports it, I see no reason why it should not be implemented. > (As said above naturally within some sane limits, you are right > that it would make no sense to have for example 50 bands.) Sliders in a consumer electronics device such as a TV are just virtual widgets on the screen, i.e. software, not physical knobs. Again, their number is fixed because of usable and "intuitive" UI. > Surely you could go for several different plugins, but I do not > see the reason why the code should be duplicated a couple > of times. The goal is to have one plugin and not a collection. > I just don't like the idea that you have to duplicate things only > because of the limitation
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
пн, 8 апр. 2019 г. в 15:05, Alexander E. Patrakov : > > пн, 8 апр. 2019 г. в 13:08, Alexander E. Patrakov : > > > I have looked again at the paper, and have a DSP question. > > > > The thesis starts with designing a shelf filter. That is, a filter > > that contains a flat area at low frequencies, a flat area at high > > frequencies (but with a different gain), and some transition in > > between. Then, for some unknown reason, it is transformed into a > > band-pass shelving filter. Then there is some talk how to "stitch" > > together several band-pass shelving filters. > > > > Why would one need to do this at all? I.e., why can't one just cascade > > several shelf filters, designed according to the correct transition > > frequencies, with the height of the shelf being the dB difference of > > the desired gains of the neighboring bands? > > Just for some context: the reason why I asked is the ripple on Figure > 2.5 that seems to be avoidable in my approach. Sorry for the stupid question. This is answered in Chapter 5. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
пт, 19 апр. 2019 г. в 14:13, Tanu Kaskinen : > If the plugin gets the number of bands during the > initialization, it can create the appropriate number of non-array > control ports. Interleaved audio ports aren't needed either, because > PulseAudio can do the deinterleaving before passing the audio to the > plugin (like module-ladspa-sink already does). If one's going to write > an LV2 plugin, it's best to use standard port types so that all hosts > will be able to use the plugin. In addition, I think that "if the plugin gets the number of bands [at runtime]" is a very big "if" for an IIR-based equalizer. So big that I would rather hard-code it, or treat equalizers with a different number of bands as completely different plugins. The reason is that the required slope of inter-band transition (i.e., effectively, the filter order) is a function of the width of each band. Implement a filter with a too-low order, and it won't be able to isolate (and thus control thegain of) a frequency band selectively enough. Implement a filter with a too-high order, and its frequency response will be too steppy. Besides, consumer electronic devices (TVs, HDMI receivers, Hi-Fi amplifiers) just do not have equalizers with a variable number of bands, for usability reasons. I don't see a reason for PulseAudio to be different. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
пн, 8 апр. 2019 г. в 13:08, Alexander E. Patrakov : > I have looked again at the paper, and have a DSP question. > > The thesis starts with designing a shelf filter. That is, a filter > that contains a flat area at low frequencies, a flat area at high > frequencies (but with a different gain), and some transition in > between. Then, for some unknown reason, it is transformed into a > band-pass shelving filter. Then there is some talk how to "stitch" > together several band-pass shelving filters. > > Why would one need to do this at all? I.e., why can't one just cascade > several shelf filters, designed according to the correct transition > frequencies, with the height of the shelf being the dB difference of > the desired gains of the neighboring bands? Just for some context: the reason why I asked is the ripple on Figure 2.5 that seems to be avoidable in my approach. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
пн, 8 апр. 2019 г. в 12:27, Georg Chini : > > On 05.04.19 13:29, Tanu Kaskinen wrote: > > On Tue, 2019-04-02 at 20:28 +0200, Georg Chini wrote: > >> On 06.11.18 22:14, Andrea A wrote: > >>> Thanks a lot for the reply > >>> > >>>> If the preset files are expected to be shared between users, then the > >>> database.h stuff isn't good, because different users can have their > >>> pulseaudio configured with different database formats. I like the "ini- > >>> style" configuration file style that pulseaudio uses for .conf files. > >>> There are no helpers for writing those files, though, but that's > >>> probably not a big issue. > >>> > >>> I can write a parser for ini-style file however since PA is > >>> multiplatform I need some information about how to store user and > >>> system settings. System settings can be hardcoded at least, but the > >>> directory of user config depends on the platform I think. > >>> > >>>> Iwould love to have the equalizer as a LADSPA plugin > >>> My fear is that a LADSPA plugin will be too hard to use for a lot of > >>> desktop users. I think that a GNU desktop user would like to have a > >>> fully working audio equalizer in his distribution and PA is default in > >>> almost all GNU distributions. Configuring a LADSPA plugin may be hard > >>> and boring for the average user and GNU will continue to don't have a > >>> standard equalizer. Beyond the issues you've already listed. > >>> > >>>> It's not very uncommon that some core > >>> change requires changes in all sinks, so even if the module is perfect > >>> and doesn't require maintenance in form of bug fixes, there are other > >>> kinds of real maintenance costs. > >>> > >>> As far as I know the actual equalizer is deprecated so if this mine > >>> equalizer will be adequate I think that the actual can be substitute > >>> and the number of modules to maintain will not change. > >>> > >>> Andrea993 > >>> > >>> > >> Hi Andrea, > >> > >> > >> maybe there is a chance now to have your equalizer included as a module. > >> The messaging API patches > >> should have their final form (at least I do not think the public > >> functions will change anymore) and today > >> I submitted a patch series that consolidates the code of the current > >> virtual sinks and moves the common > >> code to a separate file. Using the common code should significantly > >> reduce the maintenance cost of an > >> additional sink. > >> > >> So if you are still interested to have it included, at least I would > >> welcome a new patch. > >> > >> > >> Arun, Tanu, what do you think? > > I think it would anyway make sense to make one or more LADSPA plugins > > out of the equalizer code (I say one or more, because of the lack of > > parametrization support in LADSPA). That way the equalizer would be > > available also to other software than just PulseAudio (I'm thinking > > PipeWire in particular). > > > > If a suitable LADSPA plugin existed, we might or might not still need a > > separate equalizer module, but in any case we wouldn't need to maintain > > the DSP code in PulseAudio. If there's some reason why module-ladspa- > > sink isn't (and can't become) suitable for implementing the integration > > in PulseAudio, then a specialized module is fine. > > > > I'm not saying that I'm dead against hosting the DSP code in > > PulseAudio, but I'd certainly prefer not to. > > > It surely would make sense to have one or several LADSPA > plugins, but for me a good equalizer should be an integral > part of pulseaudio. And as you say yourself, the full flexibility > cannot be achieved by a single LADSPA plugin. The equalizer > we are currently providing is buggy and completely unsupported. > The new equalizer would at least be fully documented, so that > it is possible to maintain. Additionally I agree with Andrea that > handling LADSPA plugins is somewhat cumbersome. From a > user point of view, a module is much easier to handle. I have looked again at the paper, and have a DSP question. The thesis starts with designing a shelf filter. That is, a filter that contains a flat area at low frequencies, a flat area at high frequencies (but with a different gain), and some transition in between. Then, for some unknown reason, it is transformed into a band-pass shelving filter. Then there is some talk how to "stitch" together several band-pass shelving filters. Why would one need to do this at all? I.e., why can't one just cascade several shelf filters, designed according to the correct transition frequencies, with the height of the shelf being the dB difference of the desired gains of the neighboring bands? -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to disable switch on HDMI audio output ?
Georg Chini : > > On 07.03.19 12:31, Tomaž Šolc wrote: > > Hi > > > > On 1. 03. 19 12:15, Alex ARNAUD wrote: > >> As stated in the title, I'm looking for a way to disable switch to > >> HDMI audio output. > > > > I think there's currently no way to blacklist devices in the > > module-switch-on-port-available. > > > > If you never want to use HDMI audio at all, then perhaps the best way to > > solve your problem is to just make PulseAudio ignore that device > > altogether. > > > What works for me is just to set the HDMI device to "off" in the pavucontrol > configuration tab. This setting should be remembered across boots. Georg, I think you misunderstood the task. Alex is creating a LiveCD and needs to disable HDMI beforehand for all users. Just telling the user to use pavucontrol is not going to work, as the user will not be able to interact with it, if the screen reader speaks to the HDMI monitor which pretends to accept sound but does not actually have speakers. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Network audio stuttering?
Russell Treleaven : > > Is there an open bug for this? No. > > On Wed, Dec 26, 2018, 6:41 PM Alexander E. Patrakov > wrote: >> >> David Davidović : >> > >> > Hi, >> > >> > I'm running a system-wide PulseAudio instance on a headless box connected >> > to my speaker system. The sink is broadcast via Zeroconf and I use it to >> > play music and movies via WiFi from my laptop. The headless box is >> > connected to the WiFi router via a wired connection. >> > >> > Unfortunately, every couple of minutes or so, the sound stutters for a >> > short time, then returns to normal. >> > >> > Does anyone have any suggestions as to how to debug the source of these >> > issues? My best bet is WiFi latency. I tried increasing the buffer size >> > (via default-fragments and default-fragment-size-msec) on both the client >> > and server machine but I haven't seen any considerable improvement. The >> > actual network packets seem to always be around 1.5K in size, which would >> > be around 4ms of uncompressed sound with 32-bit stereo samples at 44.1kHz, >> > and that's without any overhead. If my calculation is true, this would >> > explain the stuttering, as the network latency towards the machine is at a >> > baseline of ~2ms but can spike sometimes due to nature of WiFi. >> > >> >> Packets are sent in advance, and WiFi cannot allow for bigger packets anyway. >> >> > I'd be happy if there was a way to e.g. tell the native-protocol-tcp >> > module to buffer more of the audio and play it, as I don't mind the >> > increased latency; I just want to get rid of the stuttering and all >> > applications I use manage PulseAudio latency compensation quite well. >> >> You can't. It's the media player application who requests buffering >> and specifies the latency. However, if pavucontrol is running, the >> latency is capped to something like 20 ms, due to the misguided design >> decision that monitor sinks should monitor what is written right now >> (not what is playing right now). >> >> What would help is a "pactl list sinks" on both ends while music is >> playing and pavucontrol is not running. >> >> > Has anyone else had this issue and resolved it? >> >> Yes, by closing pavucontrol. >> >> -- >> Alexander E. Patrakov >> ___________ >> pulseaudio-discuss mailing list >> pulseaudio-discuss@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Network audio stuttering?
David Davidović : > > Hi, > > I'm running a system-wide PulseAudio instance on a headless box connected to > my speaker system. The sink is broadcast via Zeroconf and I use it to play > music and movies via WiFi from my laptop. The headless box is connected to > the WiFi router via a wired connection. > > Unfortunately, every couple of minutes or so, the sound stutters for a short > time, then returns to normal. > > Does anyone have any suggestions as to how to debug the source of these > issues? My best bet is WiFi latency. I tried increasing the buffer size (via > default-fragments and default-fragment-size-msec) on both the client and > server machine but I haven't seen any considerable improvement. The actual > network packets seem to always be around 1.5K in size, which would be around > 4ms of uncompressed sound with 32-bit stereo samples at 44.1kHz, and that's > without any overhead. If my calculation is true, this would explain the > stuttering, as the network latency towards the machine is at a baseline of > ~2ms but can spike sometimes due to nature of WiFi. > Packets are sent in advance, and WiFi cannot allow for bigger packets anyway. > I'd be happy if there was a way to e.g. tell the native-protocol-tcp module > to buffer more of the audio and play it, as I don't mind the increased > latency; I just want to get rid of the stuttering and all applications I use > manage PulseAudio latency compensation quite well. You can't. It's the media player application who requests buffering and specifies the latency. However, if pavucontrol is running, the latency is capped to something like 20 ms, due to the misguided design decision that monitor sinks should monitor what is written right now (not what is playing right now). What would help is a "pactl list sinks" on both ends while music is playing and pavucontrol is not running. > Has anyone else had this issue and resolved it? Yes, by closing pavucontrol. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] improve reproducibility build
Hongxu Jia : > > While running pulseaudio out of build dir (especially for cross > compiling), we should not expose pulseaudio build path[1], it is > helpful for reproducibility build[2]. > > As commit introduced [3cae4a0 doc: Add info about running pulseaudio > from the build dir], run pulseaudio from the build dir, __OPTIMIZE__ > should be diabled, so add macro checking to drop PA_SRCDIR/PA_BUILDDIR > (in which contains build path) at precompilation. > > [1] https://reproducible-builds.org/docs/build-path/ > [2] https://reproducible-builds.org/ > > Signed-off-by: Hongxu Jia I don't believe that the doc that you are basing your decisions on is correct. Anyway, basing such decisions automagically on the optimization level is very non-obvious. Maybe it is a better idea to introduce a special build flag (for autotools it would be something like --disable-running-from-build-tree or --enable-reproducible-build) that explicitly disables running from build tree and thus enables a reproducible build? -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Weak bass in stereo mode – possibility of virtual 2.1 sound profiles
On 11/16/18 11:13 AM, Tanu Kaskinen wrote: On Thu, 2018-11-15 at 23:50 +0500, Alexander E. Patrakov wrote: Alexander E. Patrakov : Tanu Kaskinen : On Sat, 2018-10-13 at 22:29 +0500, Alexander E. Patrakov wrote: Note that I am unhappy with it, because it fixes only a particular common problem case, while other related issues stay unfixed. E.g. if one tries to play 5.1 audio on 7.1 system, with or without this patch: - Front, Center and LFE channels are mapped 1:1, which is correct - Rear (or what mpv calls "Side") source channels are mapped to Side, which is also correct, because it's the Side speakers in the ITU-T 7.1 layout, not Rear, which have the nearest position to what Dolby specifies for Surround AC3 speakers. - The true rear channels get a mix between Front and Side, which is clearly incorrect. ITU R-REC-BS.775-3-201208 says that both sets of surround channels should be fed the same signal. Regarding that last point, do I understand correctly that the recommendation is to duplicate the 5.1 rear(/side) channels to both the side and rear channels in 7.1? Doesn't that cause imbalance by amplifying the rear channels? Or is it compensated by attenuating the signal? You understood correctly. In my big patch, it is compensated by attenuating the signal. Anyway, I am going to resubmit it later today without the half-baked change about the LFE volume. Sorry, I have to do it later. I have too much non-PulseAudio work to do :( No problem, I'll postpone reviewing the patch until you've submitted the new version. From what I already saw, the general idea behind the patch seems good. Hello Tanu, thanks for your patience. I have tried to undo the half-baked LFE change today, but found two more bugs in my patch that I would rather fix before resubmitting it: 1. AUX input channels get sometimes routed to non-AUX output channels rather than being dropped. Fixing this right how. 2. Some inconsistencies if either input or output channel map contains duplicates. Cannot really fix, because I don't know what's expected. Could you please help with (2)? In particular, what would be the expected channel matrix in the following two cases? Case A: front-left, front-right, front-center -> front-left, front-right, front-center, front-center I would guess that we should generate two identical front-center output channels, both duplicating the front-center input channel with the coefficient being 1.0. Case B: front-left, front-right, front-left, front-right -> front-left, front-right Would it be OK if I drop the redundant input channels, i.e. use only the first copy of each channel name? Or should I average the redundant inputs, or take a sum? Is there any spec? -- Alexander E. Patrakov smime.p7s Description: S/MIME Cryptographic Signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Weak bass in stereo mode – possibility of virtual 2.1 sound profiles
Alexander E. Patrakov : > > Tanu Kaskinen : > > > > On Sat, 2018-10-13 at 22:29 +0500, Alexander E. Patrakov wrote: > > > On 10/7/18 6:27 PM, Alexander E. Patrakov wrote: > > > > вс, 7 окт. 2018 г. в 16:42, Karl Ove Hufthammer > > > <mailto:k...@huftis.org>>: > > > > > > > > Alexander E. Patrakov skreiv 07.10.2018 09:44: > > > > > > > > > > I don’t understand why this is happening. Shouldn’t > > > > > ‘remixing-use-all-sink-channels = no’ just affect *upmixing* > > > > of > > > > > sound, > > > > > and leave 5.1 material alone? > > > > > > > > > > > > > > > This is a known bug that appears because there are two 5.1 > > > > standards: > > > > > proper 5.1 and 5.1 Side. The video player (I guess you use mpv) > > > > says: > > > > > the extra two channels have to come from the side. > > > > > > > > Looks like you’re right. If I run ‘ffprobe’ on my 5.1 test file, it > > > > returns: > > > > > > > > Stream #0:1[0x1100]: Audio: dts (DTS-HD MA) ([134][0][0][0] / > > > > 0x0086), 48000 Hz, 5.1(side), s32p (24 bit) > > > > > > > > So the video file (and mpv) seems to use the ‘5.1(side)’ standard. > > > > (Which is a bit strange, since this is supposed to be a video file > > > > to > > > > test a normal 5.1 setup, AFAICS.) > > > > > > > > > > > > (speaking with my "DTS encoder author" hat on) > > > > > > > > The issue is that it is a DTS file. DTS uses completely different > > > > channel names than what's found in PulseAudio source. The proper > > > > normative reference is: > > > > > > > > https://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf > > > > page 19, table 5.4 (note that the presence of the LFE channel is > > > > transmitted separately). > > > > > > > > Your file uses AMODE=0b001001=9, so the list of channels is: "Center", > > > > "Left", "Right", "Surround Left", "Surround Right". And there is also a > > > > 64x downsampled LFE channel. FFMmpeg-based decoders map "Surround" to > > > > "Side" because "Rear" also exists in other channel layouts and means > > > > something different. There is no way in DTS to express a layout with > > > > "Rear" but no "Surround" channels. > > > > > > > > > > > > > > > > > But your system does not have speakers there, it has them on the > > > > rear. > > > > > So PulseAudio attempts to remix. In fact, sound both with and > > > > without > > > > > remixing-use-all-sink-channels is wrong. > > > > > > > > What’s wrong about the remixing when one uses > > > > ‘remixing-use-all-sink-channels = yes’? > > > > > > > > > > > > The rear channels will get not a copy of the side, but an average of > > > > front and side. > > > > > > As promised, here is a patch. > > > > Thanks a lot! Very nice fix for a common problem, I applied it now. I > > expect to look into the big remixing rework patch soon. > > > > > Note that I am unhappy with it, because it fixes only a particular > > > common problem case, while other related issues stay unfixed. E.g. if > > > one tries to play 5.1 audio on 7.1 system, with or without this patch: > > > > > > - Front, Center and LFE channels are mapped 1:1, which is correct > > > - Rear (or what mpv calls "Side") source channels are mapped to Side, > > > which is also correct, because it's the Side speakers in the ITU-T 7.1 > > > layout, not Rear, which have the nearest position to what Dolby > > > specifies for Surround AC3 speakers. > > > - The true rear channels get a mix between Front and Side, which is > > > clearly incorrect. ITU R-REC-BS.775-3-201208 says that both sets of > > > surround channels should be fed the same signal. > > > > Regarding that last point, do I understand correctly that the > > recommendation is to duplicate the 5.1 rear(/side) channels to both the > > side and rear channels in 7.1? Doesn't that cause imbalance by > > amplifying the rear channels? Or is it compensated by attenuating the > > signal? > > You understood correctly. In my big patch, it is compensated by > attenuating the signal. Anyway, I am going to resubmit it later today > without the half-baked change about the LFE volume. Sorry, I have to do it later. I have too much non-PulseAudio work to do :( -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Weak bass in stereo mode – possibility of virtual 2.1 sound profiles
Tanu Kaskinen : > > On Sat, 2018-10-13 at 22:29 +0500, Alexander E. Patrakov wrote: > > On 10/7/18 6:27 PM, Alexander E. Patrakov wrote: > > > вс, 7 окт. 2018 г. в 16:42, Karl Ove Hufthammer > > <mailto:k...@huftis.org>>: > > > > > > Alexander E. Patrakov skreiv 07.10.2018 09:44: > > > > > > > > I don’t understand why this is happening. Shouldn’t > > > > ‘remixing-use-all-sink-channels = no’ just affect *upmixing* of > > > > sound, > > > > and leave 5.1 material alone? > > > > > > > > > > > > This is a known bug that appears because there are two 5.1 > > > standards: > > > > proper 5.1 and 5.1 Side. The video player (I guess you use mpv) > > > says: > > > > the extra two channels have to come from the side. > > > > > > Looks like you’re right. If I run ‘ffprobe’ on my 5.1 test file, it > > > returns: > > > > > > Stream #0:1[0x1100]: Audio: dts (DTS-HD MA) ([134][0][0][0] / > > > 0x0086), 48000 Hz, 5.1(side), s32p (24 bit) > > > > > > So the video file (and mpv) seems to use the ‘5.1(side)’ standard. > > > (Which is a bit strange, since this is supposed to be a video file to > > > test a normal 5.1 setup, AFAICS.) > > > > > > > > > (speaking with my "DTS encoder author" hat on) > > > > > > The issue is that it is a DTS file. DTS uses completely different > > > channel names than what's found in PulseAudio source. The proper > > > normative reference is: > > > > > > https://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf > > > page 19, table 5.4 (note that the presence of the LFE channel is > > > transmitted separately). > > > > > > Your file uses AMODE=0b001001=9, so the list of channels is: "Center", > > > "Left", "Right", "Surround Left", "Surround Right". And there is also a > > > 64x downsampled LFE channel. FFMmpeg-based decoders map "Surround" to > > > "Side" because "Rear" also exists in other channel layouts and means > > > something different. There is no way in DTS to express a layout with > > > "Rear" but no "Surround" channels. > > > > > > > > > > > > > But your system does not have speakers there, it has them on the > > > rear. > > > > So PulseAudio attempts to remix. In fact, sound both with and > > > without > > > > remixing-use-all-sink-channels is wrong. > > > > > > What’s wrong about the remixing when one uses > > > ‘remixing-use-all-sink-channels = yes’? > > > > > > > > > The rear channels will get not a copy of the side, but an average of > > > front and side. > > > > As promised, here is a patch. > > Thanks a lot! Very nice fix for a common problem, I applied it now. I > expect to look into the big remixing rework patch soon. > > > Note that I am unhappy with it, because it fixes only a particular > > common problem case, while other related issues stay unfixed. E.g. if > > one tries to play 5.1 audio on 7.1 system, with or without this patch: > > > > - Front, Center and LFE channels are mapped 1:1, which is correct > > - Rear (or what mpv calls "Side") source channels are mapped to Side, > > which is also correct, because it's the Side speakers in the ITU-T 7.1 > > layout, not Rear, which have the nearest position to what Dolby > > specifies for Surround AC3 speakers. > > - The true rear channels get a mix between Front and Side, which is > > clearly incorrect. ITU R-REC-BS.775-3-201208 says that both sets of > > surround channels should be fed the same signal. > > Regarding that last point, do I understand correctly that the > recommendation is to duplicate the 5.1 rear(/side) channels to both the > side and rear channels in 7.1? Doesn't that cause imbalance by > amplifying the rear channels? Or is it compensated by attenuating the > signal? You understood correctly. In my big patch, it is compensated by attenuating the signal. Anyway, I am going to resubmit it later today without the half-baked change about the LFE volume. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
Mikael Nousiainen : > > On Thu, Nov 8, 2018, at 20:49, > pulseaudio-discuss-requ...@lists.freedesktop.org wrote: > > Message: 4 > > Date: Thu, 8 Nov 2018 21:31:52 +0500 > > From: "Alexander E. Patrakov" > > To: General PulseAudio Discussion > > > > Subject: Re: [pulseaudio-discuss] PulseAudio null sink monitor gives > > distorted audio randomly > > Message-ID: > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > [resending to the list, really this time] > > > > On 11/8/18 7:44 PM, Tanu Kaskinen wrote: > > > > > The problem is most likely due to this bug regarding monitor sources: > > > https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/304 > > > > > > Whenever the monitored sink has a rewind, a chunk of audio is > > > apparently duplicated in the monitor source. It would be great if > > > someone could figure out what goes wrong in the monitor rewinding code. > > > > Let me quote the main mistake, from src/pulse/stream.h: > > > > > * The latency is stored in \a *r_usec. In case the stream is a > > > * monitoring stream the result can be negative, i.e. the captured > > > * samples are not yet played. In this case \a *negative is set to 1. > > > > I.e., the design mistake is that monitor sources allow one to capture > > samples that have not yet been played. This is always wrong, as those > > samples can be overwritten by a rewind, and there is no "uncapture" to > > compensate. So the fix would be to make sure that monitor sources > > capture not what was just written to them, but what was actually played > > and can no longer be overwritten. I.e., change the latency from negative > > to small positive. > > > > -- > > Alexander E. Patrakov > > Thanks for digging into this! > > Some questions: > > 1. Is there any workaround for this without a proper bugfix and a new release? > 2. Is this a question of buffer underrun / jitter bcause of CPU usage? What > is the cause for "monitor rewinds", why is it needed? > 3. Why are the artifacts gone sometimes and sometimes the appear after > PulseAudio restart? 1. No. 2. This is unlikely to be related to CPU usage. Rewinds typically happen when new streams appear, or when something changes the volume. To figure out for sure, please run PulseAudio with very very verbose logging, see below. It will then announce the reason for each rewind. 3. No idea, see the log. Actually, it is still only a speculation (or, if you prefer, educated guess) that your problem is related to rewinds. If PulseAudio does not log anything about a rewind, then that's not it. Here is how to run PulseAudio with very very verbose logging; 1. Edit ~/.config/pulse/client.conf, so that it contains exactly one line: autospawn=no 2. systemctl --user stop pulseaudio.socket pulseaudio.service 3. pulseaudio -vvv 2>&1 | tee -i pulseaudio.log 4. Reproduce the problem 5. Ctrl+C, revert the change to ~/.config/pulse/client.conf, systemctl --user start pulseaudio.socket pulseaudio.service 6. Send the log here. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
[resending to the list, really this time] On 11/8/18 7:44 PM, Tanu Kaskinen wrote: The problem is most likely due to this bug regarding monitor sources: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/304 Whenever the monitored sink has a rewind, a chunk of audio is apparently duplicated in the monitor source. It would be great if someone could figure out what goes wrong in the monitor rewinding code. Let me quote the main mistake, from src/pulse/stream.h: * The latency is stored in \a *r_usec. In case the stream is a * monitoring stream the result can be negative, i.e. the captured * samples are not yet played. In this case \a *negative is set to 1. I.e., the design mistake is that monitor sources allow one to capture samples that have not yet been played. This is always wrong, as those samples can be overwritten by a rewind, and there is no "uncapture" to compensate. So the fix would be to make sure that monitor sources capture not what was just written to them, but what was actually played and can no longer be overwritten. I.e., change the latency from negative to small positive. -- Alexander e. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] PulseAudio null sink monitor gives distorted audio randomly
Mikael Nousiainen : > I've got a very weird issue with PulseAudio when trying to route audio > from one application (Firefox 64.0b7 (64-bit)) to another one (WSJT-X v1.9.1). > I'm experiencing the same issue with different browsers (Chrome and Chromium > too). > The browser is receiving audio from a radio transceiver through a WebRTC > connection and I'm feeding it to WSJT-X to decode the data in the audio > signal. > > I'm using two module-null-sink modules to transfer the audio between > the browser and WSJT-X. I use pavucontrol to make the browser play audio to > null sink called "radio-output" and then let WSJT-X listen to the audio > via "radio-output.monitor". The kind of setup exists for transmitted audio > where WSJT-X feeds audio to the browser through a null sink called > "radio-input". > > However, the issue her is that WSJT-X is mostly not able to decode the data > when it's using "radio-output.monitor" as audio input. Sometimes it works > and sometimes it does not. As a technical detail, I'm trying to decode FT8 > digital mode traffic and I've confirmed that the reason is not related to > bad time sync (which FT8 requires), because I can even play the browser > audio through laptop speakers and let WSJT-X use the laptop microphone as > audio input and it decodes the data just fine -- the audio sounds clean > and strong with no audible artifacts. We need to figure out whether this is due to a monitor or due to a null sink. Could you please let the browser play to your speakers, and WSJT-X record from the monitor of the sound card that the browser is playing to? Does it work? Is the webrtc feed public? I.e., can I run WSJT-X locally in order to reproduce the issue? -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
Andrea A : > My fear is that a LADSPA plugin will be too hard to use for a lot of desktop > users. I think that a GNU desktop user would like to have a fully working > audio equalizer in his distribution and PA is default in almost all GNU > distributions. Configuring a LADSPA plugin may be hard and boring for the > average user and GNU will continue to don't have a standard equalizer. Beyond > the issues you've already listed. No, it won't. It will be compiled as a part of your application, and your GUI application, at startup, would do the equivalent of "pactl load-module module-ladspa-sink" with the correct parameters for each existing sink. I.e. the user will only have to install your application from a distribution package and logout/login again. And we have a good precedent here: veromix _was_ packaged in Debian (now it isn't because it is not up to speed with recent KDE and GNOME), and it uses exactly the proposed architecture. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] New equalizer module (module-eqpro-sink), some questions
Tanu Kaskinen : > Thanks for contributing to this thread :) > On Mon, 2018-11-05 at 00:14 +0500, Alexander E. Patrakov wrote: > > Andrea A : > > > I'm writing a new equalizer module for PA, > > > https://github.com/andrea993/audioeqpro/blob/master/pulsemodule/module-eqpro-sink.c > > > I've almost done but I need some information from developer about how to > > > proceed. > > > > Thanks for attempting a contribution. I have attempted to answer your > > questions regarding the integration, please read below. However, see > > the end of this email for the biggest reason why I am against > > accepting this module or any future form of it (but my "no" holds very > > little weight, so feel free to ignore it). > > > > However, in order for the module to be accepted (barring the big > > objection at the bottom of this email), we need to review the DSP > > part, and not just the integration part. It would help if you provide, > > in the form of comments in the source code, some references where the > > math comes from. And use more descriptive variable names, such as K -> > > extra_gain. Also, I think it would make sense to use a struct of 10 > > well-named floats instead of eqp->c. > > > > > First of all, I see that current equalizer module manages > > > "autoloaded" have I to manage it? What it does exactly? Old > > > equalizer check "autoloaded" state in a callback "may_move_to", > > > what is it? Have I to implement this callback and manage > > > "autoloaded" like the current equalizer module? > > > > It is set by module_filter_apply. The intended effect is to prevent > > moving the output of the equalizer to a different sink - i.e. if it > > was autoloaded for "Built-in Audio Analog Stereo" then you cannot move > > it to "HDMI Digital Stereo" using pavucontrol. See > > module-virtual-surround-sink.c for known-good usage. Although, I don't > > know any user of module_filter_apply. > > > > Regarding the may_move_to callback, it is called when a user tries to > > move the equalizer output to a different sink. Please at least prevent > > creating a loop, i.e. moving the output to the equalizer itself. > > There's no need to worry about loops, pa_sink_input_may_move_to() > already checks that (except loops built using module-loopback aren't > checked, but Andrea probably isn't going to solve that problem anyway, > or if he is, it's better to solve that in pa_sink_input_move_to() > rather than in individual modules). > > > > After the "autoloaded" management I can send the equalizer as a > > > patch, however I've some questions about how to add my equalizer > > > GUI to the PA branch. Should the GUI remains an external program or > > > the GUI will be inserted to the mainline sources? In the second > > > scenario how the GUI should be inserted? Which is the correct > > > directory in the sources tree and what about the GUI makefile and > > > the GUI installation directory? > > > > PulseAudio currently does not depend on any GUI toolkit (well, except > > the old equalizer GUI). Personally, I am fine with this GUI (or maybe > > two GUIs - one for GNOME and MATE and XFCE, one for KDE) being in > > external repositories. > > GUIs should go to external repositories. qpaeq is an exception, and > probably not that well justified exception. One reason qpaeq made its > way to the main pulseaudio repo was that it's just a simple python > script that doesn't need much support from the build system. > > > > The equalizer needs the messages patches from George Chini > > > https://patchwork.freedesktop.org/series/41390/ > > > Have I to write this information as a patch comment or other? > > > > Patch comment. > > I'm not sure what "patch comment" means, but the information doesn't > belong in the commit message. If the module is submitted as a merge > request in GitLab, the information can be written to the merge request > description or added as a separate comment in the discussion section. > If the module is submitted via email, the information can be added > below the "---" line in the patch (this stuff is explained at > https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/ > ). The stuff below the "---" line is what I meant. I am not entirely comfortable with GitLab merge requests, but that's a problem with me, not with GitLab. And in this case a comment on the merge request would definitely work. > > > I would like to add some configur
Re: [pulseaudio-discuss] R: New equalizer module (module-eqpro-sink), some questions
Andrea A : > > I’ve just added the thesis link at the end of the first module comment, I can > change its position if you want: > > https://github.com/andrea993/audioeqpro/blob/afb986711f5125083351cc4f7dac1ca84409f501/pulsemodule/module-eqpro-sink.c#L21 Thank you very much, I will look. It will be slower than usual because I will have to use Google Translate. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] New equalizer module (module-eqpro-sink), some questions
Andrea A : > My equalizer is my thesis and math model comes from about 70 pages of > calculations. It is not possible to add them as source comments. In my thesis > I have inserted and explained only relevant result, and to do only this I've > spent about 40 pages. Then please publish your thesis online somewhere as a pdf and insert a link to it in the source code as a comment. P.S. in some countries, including Russia, such publication is required anyway. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] New equalizer module (module-eqpro-sink), some questions
n instead. PulseAudio already has module-lasdpa-sink since ages (even with D-Bus interface to change parameters at runtime), so your filter will be available also to all users of old PulseAudio versions. It will be also available to users of pure ALSA-based setup, if they still exist. You can publish improvements any time you want, without needing any potentially slow review from PulseAudio maintainers (but feel free to contact me privately if you do need a review), and your module will be quick to compile, because it is separated from the rest of PulseAudio. You can then publish a GUI application that loads the module into PulseAudio and then controls its filter via D-Bus. And you don't need to care about rewinds and may_move_to and all other pulseaudio-specific boilerplate. Sounds like a win-win situation. Could you please investigate this approach? Thanks again for attempting to replace the current equalizer with something better. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] WIP/RFC: completely rewritten channel remixing
The current code in PulseAudio for channel remixing is quite complex,
has a lot of ifs, and does not do the right thing. For example:
1) Given a "5.1 (Side)" sink input and "5.1" sink, it generates the rear
channels as averages between Front and Side instead of just using Side.
2) The coefficients for downmixing rear channels from a 5.1 sink input
to a stereo sink are very low. On compositions like "Lichtmond 2" it is
quite annoying. AC3 specifies the -3 or -6 dB downmix level, which means
dividing by 1.4 or by 2, not by 9.
3) The coefficient for downmixing Left channel into LFE (and thus the
tonal balance) is different when playing stereo and 5.0 material on a
5.1 sink.
I found that I can get rid of a lot of complexity, while reproducing
most (all?) of the good decisions that the old code did, by using a
simple notion of "channel azimuth" and "channel proximity", and
reordering the algorithm so that it first tries to use all input
channels and then to fill unused output channels.
Each input channel is routed to one (or, if the situation is too
symmetrical, two) output channels that are nearest to its position.
Then, each unused output channel is filled in from one (or, in
symmetrical cases, two) input channels that are the closest ones to its
position. That's it, no need to explicitly consider special cases of
exactly matching channels or mono layout. The old code was so complex
because it did not know the word "nearest".
While at it, I also tried to fix cases (2) and (3). The resulting patch
is attached. Yes, it is unreadable, as it typically happens with big
rewrites.
Here is an example channel matrix for 5.1(Side) -> Stereo remapping with
the new patch:
I00 I01 I02 I03 I04 I05
+
O00 | 0,385 0,000 0,192 0,192 0,231 0,000
O01 | 0,000 0,385 0,192 0,192 0,000 0,231
Here is 5.1(Side) -> 5.1:
I00 I01 I02 I03 I04 I05
+
O00 | 1,000 0,000 0,000 0,000 0,000 0,000
O01 | 0,000 1,000 0,000 0,000 0,000 0,000
O02 | 0,000 0,000 0,000 0,000 1,000 0,000
O03 | 0,000 0,000 0,000 0,000 0,000 1,000
O04 | 0,000 0,000 1,000 0,000 0,000 0,000
O05 | 0,000 0,000 0,000 1,000 0,000 0,000
Here is Stereo -> 5.1, with fill-all-channels enabled and LFE remixing
disabled:
I00 I01
+
O00 | 1,000 0,000
O01 | 0,000 1,000
O02 | 0,600 0,000
O03 | 0,000 0,600
O04 | 0,500 0,500
O05 | 0,000 0,000
The patch is definitely not baked enough, e.g. it attenuates too much
when LFE remixing is going on with 5.1 or 7.1 input. Also, there might
be bugs and corner cases that I haven't thought about. Testing and
criticizing is welcome, inclusion in the official tree is probably not a
good idea.
The patch is an alternative approach to what was solved by
https://lists.freedesktop.org/archives/pulseaudio-discuss/2018-October/030559.html
, do not try to apply both.
--
Alexander E. Patrakov
From c26c3f2806fbf5ae200a2a34425a3e2a58c8533f Mon Sep 17 00:00:00 2001
From: "Alexander E. Patrakov"
Date: Sun, 14 Oct 2018 06:54:28 +0500
Subject: [PATCH] resampler: Completely rewritten channel remapping
The new implementation is based on geometrical considerations like
angles between the center channel and other channels, and the notion
of channel proximity.
It never does such stupidity as using front-left-of-center to fill
the rear-left channel if front-left is also present.
It also automatically deals with confusion between "5.1" and "5.1
(Side)" which is common in media players.
It is less lines of code than the old logic, and has much less special
cases.
It does not yield exactly the same result, that's intentional.
Signed-off-by: Alexander E. Patrakov
---
src/pulsecore/resampler.c | 638 +-
1 file changed, 286 insertions(+), 352 deletions(-)
diff --git a/src/pulsecore/resampler.c b/src/pulsecore/resampler.c
index d42cbc298..06bd1f93a 100644
--- a/src/pulsecore/resampler.c
+++ b/src/pulsecore/resampler.c
@@ -21,6 +21,7 @@
#include
#endif
+#include
#include
#include
@@ -40,7 +41,7 @@ struct ffmpeg_data { /* data specific to ffmpeg */
static int copy_init(pa_resampler *r);
-static void setup_remap(const pa_resampler *r, pa_remap_t *m, bool *lfe_remixed);
+static void setup_remap(const pa_resampler *r, pa_remap_t *m, unsigned crossover_freq, bool *lfe_remixed);
static void free_remap(pa_remap_t *m);
static int (* const init_table[])(pa_resampler *r) = {
@@ -320,7 +321,7 @@ pa_resampler* pa_resampler_new(
const pa_channel_map *am,
const pa_sample_spec *b,
const pa_channel_map *bm,
- unsigned crossover_freq,
+unsigned crossover_freq,
pa_resample_method_t method,
pa_resample_flags_t flags) {
@@ -414,7 +415,7 @@ pa_resampler* pa_resampler_new(
Re: [pulseaudio-discuss] Weak bass in stereo mode – possibility of virtual 2.1 sound profiles
On 10/7/18 6:27 PM, Alexander E. Patrakov wrote: вс, 7 окт. 2018 г. в 16:42, Karl Ove Hufthammer <mailto:k...@huftis.org>>: Alexander E. Patrakov skreiv 07.10.2018 09:44: > > I don’t understand why this is happening. Shouldn’t > ‘remixing-use-all-sink-channels = no’ just affect *upmixing* of > sound, > and leave 5.1 material alone? > > > This is a known bug that appears because there are two 5.1 standards: > proper 5.1 and 5.1 Side. The video player (I guess you use mpv) says: > the extra two channels have to come from the side. Looks like you’re right. If I run ‘ffprobe’ on my 5.1 test file, it returns: Stream #0:1[0x1100]: Audio: dts (DTS-HD MA) ([134][0][0][0] / 0x0086), 48000 Hz, 5.1(side), s32p (24 bit) So the video file (and mpv) seems to use the ‘5.1(side)’ standard. (Which is a bit strange, since this is supposed to be a video file to test a normal 5.1 setup, AFAICS.) (speaking with my "DTS encoder author" hat on) The issue is that it is a DTS file. DTS uses completely different channel names than what's found in PulseAudio source. The proper normative reference is: https://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf page 19, table 5.4 (note that the presence of the LFE channel is transmitted separately). Your file uses AMODE=0b001001=9, so the list of channels is: "Center", "Left", "Right", "Surround Left", "Surround Right". And there is also a 64x downsampled LFE channel. FFMmpeg-based decoders map "Surround" to "Side" because "Rear" also exists in other channel layouts and means something different. There is no way in DTS to express a layout with "Rear" but no "Surround" channels. > But your system does not have speakers there, it has them on the rear. > So PulseAudio attempts to remix. In fact, sound both with and without > remixing-use-all-sink-channels is wrong. What’s wrong about the remixing when one uses ‘remixing-use-all-sink-channels = yes’? The rear channels will get not a copy of the side, but an average of front and side. As promised, here is a patch. Note that I am unhappy with it, because it fixes only a particular common problem case, while other related issues stay unfixed. E.g. if one tries to play 5.1 audio on 7.1 system, with or without this patch: - Front, Center and LFE channels are mapped 1:1, which is correct - Rear (or what mpv calls "Side") source channels are mapped to Side, which is also correct, because it's the Side speakers in the ITU-T 7.1 layout, not Rear, which have the nearest position to what Dolby specifies for Surround AC3 speakers. - The true rear channels get a mix between Front and Side, which is clearly incorrect. ITU R-REC-BS.775-3-201208 says that both sets of surround channels should be fed the same signal. But the needed refactoring (e.g. choosing what to mix where based on speaker azimuths) is way too big, so I decided to postpone it. -- Alexander E. Patrakov >From dc03008eb79f899c50b9d29a87245962399728ec Mon Sep 17 00:00:00 2001 From: "Alexander E. Patrakov" Date: Sat, 13 Oct 2018 22:11:20 +0500 Subject: [PATCH] resampler: Fix confusion between rear and side channels for 5.1 layouts mpv and vlc play "normal" 5.1 AC3 and DTS files as if they had a "5.1 (Side)" layout. Which is fine and consistent with ITU recommendations if the user has a proper 7.1 system. But if the user actually has a 5.1 system, PulseAudio will try to remap, poorly, between the "5.1 (Side)" and "5.1" layouts, sending either an average between front and rear channels, or an attenuated version of that average, depending on the remixing-use-all-sink-channels setting. This is not desired, the "Side" channels should be sent to "Rear", it is only an unfortunate nomenclature confusion. This patch does not fix 5.1 <-> 7.1 remixing. Signed-off-by: Alexander E. Patrakov --- src/pulsecore/resampler.c | 22 ++ 1 file changed, 22 insertions(+) diff --git a/src/pulsecore/resampler.c b/src/pulsecore/resampler.c index d42cbc298..6a4ded690 100644 --- a/src/pulsecore/resampler.c +++ b/src/pulsecore/resampler.c @@ -914,6 +914,8 @@ static void setup_remap(const pa_resampler *r, pa_remap_t *m, bool *lfe_remixed) * The algorithm works basically like this: * * 1) Connect all channels with matching names. + *This also includes fixing confusion between "5.1" and + *"5.1 (Side)" layouts, done by mpv. * * 2) Mono Handling: *S:Mono: See setup_oc_mono_map(). @@ -1006,6 +1008,2
Re: [pulseaudio-discuss] Weak bass in stereo mode – possibility of virtual 2.1 sound profiles
вс, 7 окт. 2018 г. в 16:42, Karl Ove Hufthammer : > Alexander E. Patrakov skreiv 07.10.2018 09:44: > > > > I don’t understand why this is happening. Shouldn’t > > ‘remixing-use-all-sink-channels = no’ just affect *upmixing* of > > sound, > > and leave 5.1 material alone? > > > > > > This is a known bug that appears because there are two 5.1 standards: > > proper 5.1 and 5.1 Side. The video player (I guess you use mpv) says: > > the extra two channels have to come from the side. > > Looks like you’re right. If I run ‘ffprobe’ on my 5.1 test file, it > returns: > >Stream #0:1[0x1100]: Audio: dts (DTS-HD MA) ([134][0][0][0] / > 0x0086), 48000 Hz, 5.1(side), s32p (24 bit) > > So the video file (and mpv) seems to use the ‘5.1(side)’ standard. > (Which is a bit strange, since this is supposed to be a video file to > test a normal 5.1 setup, AFAICS.) > (speaking with my "DTS encoder author" hat on) The issue is that it is a DTS file. DTS uses completely different channel names than what's found in PulseAudio source. The proper normative reference is: https://www.etsi.org/deliver/etsi_ts/102100_102199/102114/01.03.01_60/ts_102114v010301p.pdf page 19, table 5.4 (note that the presence of the LFE channel is transmitted separately). Your file uses AMODE=0b001001=9, so the list of channels is: "Center", "Left", "Right", "Surround Left", "Surround Right". And there is also a 64x downsampled LFE channel. FFMmpeg-based decoders map "Surround" to "Side" because "Rear" also exists in other channel layouts and means something different. There is no way in DTS to express a layout with "Rear" but no "Surround" channels. > > > > But your system does not have speakers there, it has them on the rear. > > So PulseAudio attempts to remix. In fact, sound both with and without > > remixing-use-all-sink-channels is wrong. > > What’s wrong about the remixing when one uses > ‘remixing-use-all-sink-channels = yes’? > The rear channels will get not a copy of the side, but an average of front and side. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Weak bass in stereo mode – possibility of virtual 2.1 sound profiles
пт, 5 окт. 2018 г. в 21:55, Karl Ove Hufthammer : > > But, strangely, real 5.1 material are now somewhat messed up. I use the > wonderful > >hd_dts_hd_master_audio_sound_check_5_1_lossless.m2ts > > video file (available several places on the Web – I’m not sure what its > original Web site is) as a test file. The front left/right/centre sounds > are OK. But when the rear right sound is played, the sound is mainly > coming from my *front* right speaker (though *some* sound is also coming > from my rear right speaker). And the sound volume is much when playing > the sound is much lower than for the front left/right/centre sounds. For > the rear left sound, a similar thing happens; i.e. the sound is mainly > coming from my *front* left speaker. > > I don’t understand why this is happening. Shouldn’t > ‘remixing-use-all-sink-channels = no’ just affect *upmixing* of sound, > and leave 5.1 material alone? > This is a known bug that appears because there are two 5.1 standards: proper 5.1 and 5.1 Side. The video player (I guess you use mpv) says: the extra two channels have to come from the side. But your system does not have speakers there, it has them on the rear. So PulseAudio attempts to remix. In fact, sound both with and without remixing-use-all-sink-channels is wrong. Solutions: either upgrade to a 7.1 system or use a different player that doesn't care about Side and Rear. Totem or anything other GStreamer-based should work fine. But in reality this should be fixed in PulseAudio code. Maybe I will work on it next week. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Weak bass in stereo mode – possibility of virtual 2.1 sound profiles
пт, 5 окт. 2018 г. в 12:36, Karl Ove Hufthammer : > Hi! > > I use my NVIDIA graphics card as a combined graphics and sound card, > connected to my 5.1 home theatre system via an HDMI cable (something > which works surprisingly well). Using the default audio profiles in > ‘pavucontrol’, I can easily switch between 5.1 sound (e.g. for DVDs) and > stereo sound, which is great. > Hello! I think you forgot to specify the version of PulseAudio... > > The 5.1 profile (‘hdmi-surround-extra1’) also work fine for *some* > stereo material, mainly music. But for *most* stereo material, the > upmixing makes everything sound too echoey (this is typically a problem > for movies with just stereo sound and for vocal-heavy music), so I > usually just use the stereo profile (‘hdmi-stereo-extra1’) for stereo > material. > There is a setting that prohibits upmixing (i.e. filling the rear channels with a copy of front). It is called remixing-use-all-sink-channels=false. But it is a relatively recent addition. It does exist in Ubuntu 18.04. > > But I have noticed than when playing music or videos using the stereo > profile, the sound is missing quite some oomph, i.e. the bass is *much* > weaker (compared to the same material played using the 5.1 profile). > > I guess the reason is that PulseAudio outputs a pure stereo sound, and > my home theatre system doesn’t redirect enough of the low-frequency > sound to my subwoofer. And unfortunately, my (not too expensive) home > theatre system doesn’t have any options for increasing this (for HDMI > audio). > Are you sure that the subwoofer gets anything at all in this mode? Anyway the suggestion is to try the 5.1 profile and remixing-use-all-sink-channels=false. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bluetooth aptX codec
ly SBC, but also those other aptX, MPEG1/2, AAC and > > > LDAC codecs) > > > > So I continue to disagree. Using a generic framework and letting other > > parts of the system select the codec implementation is what makes sense for > > the widest set of use-cases (this also allows products to ship their own > > implementations of a codec without changing the PulseAudio code). > > Still this is not enough for bluetooth codec. For specific codec you > need to create bluez dbus endpoint with codec specific parameters. Plus > implement select and set methods to decide on codec parameters between > pulseaudio and bluetooth headset. And finally to send encoded data you > need to know how to send them. To which endpoint, how header looks like > etc... Some codecs needs to wrap data into RTP (e.g. SBC), some must not > have RTP (e.g. aptX). And after that comes data from codec encoder > function. > > So is there any library which all above support? I have not find > anything. Nor ffmpeg nor gstreamer. > > Which means that pulseaudio cannot delegate codec selection, codec > initialization and codec encoding to some external library (yet). > > Anyway, now in bluez source code is some kind of codec encoding support > for android systems. Therefore should not be a wise idea to move all > these codec A2DP mess into bluez source code? Because now part of A2DP > is in bluez and another part in pulseaudio. And on android is everything > in bluez now. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] format: Fix rate for HBR passthrough formats
2018-05-25 22:15 GMT+08:00 Arun Raghavan <a...@arunraghavan.net>: > On Tue, 22 May 2018, at 4:32 PM, Alexander E. Patrakov wrote: >> There is some Microsoft documentation that contradicts this code. >> >> https://msdn.microsoft.com/en-us/library/windows/desktop/dd316761(v=vs.85).aspx >> >> """ >> Dolby TrueHD (MAT) >> >> Dolby TrueHD content is transmitted over IEC 60958 at 176.4 kHz / 8 >> channels (requiring an IEC 60958 frame rate of 705.6 kHz) for content >> sample rates of 44.1, 88.2 and 176.4 kHz, and 192 kHz / 8 channels >> (requiring an IEC 60958 frame rate of 768 kHz) for content sample >> rates of 48, 96 and 192 kHz. >> """ > > Based on Peter's input in a private thread, seems this is not the case on > Linux: > > https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp#L135 > https://github.com/xbmc/xbmc/blob/master/xbmc/cores/AudioEngine/Sinks/AESinkALSA.cpp#L486 I have looked, and also obtained a copy of IEC 61937-5-2006 standard, and I think I understand where this discrepancy comes from. The issue is that the standard does not define at all what to do if the sample rate of DTS audio is not a multiple of 48 kHz. I.e., it does not even cover the DTS CD case (44.1 kHz) that de-facto exists! Still, I think that diverging from what Windows does is not a good thing. Has anyone tested that passthrough works with DTS-HD streams that are not with a sample rate that is a multiple of 48 kHz? Does anyone have such DTS-HD stream at all? > > Cheers, > Arun > >> 2018-05-22 12:13 GMT+08:00 Arun Raghavan <a...@arunraghavan.net>: >> > In high bitrate mode, we force 192kHz/8ch as the sample format, which is >> > the expectation for HBR formats (as that is what allows for the largest >> > possible packet size). >> > --- >> > src/pulsecore/core-format.c | 3 +++ >> > 1 file changed, 3 insertions(+) >> > >> > diff --git a/src/pulsecore/core-format.c b/src/pulsecore/core-format.c >> > index 862a74b5d..096acc3a2 100644 >> > --- a/src/pulsecore/core-format.c >> > +++ b/src/pulsecore/core-format.c >> > @@ -248,6 +248,9 @@ int pa_format_info_to_sample_spec_fake(const >> > pa_format_info *f, pa_sample_spec * >> > >> > if (f->encoding == PA_ENCODING_EAC3_IEC61937) >> > ss->rate *= 4; >> > +else if ((f->encoding == PA_ENCODING_TRUEHD_IEC61937) || >> > + (f->encoding == PA_ENCODING_DTSHD_IEC61937)) >> > + ss->rate = 192000; >> > >> > return 0; >> > } >> > -- >> > 2.17.0 >> > >> > ___ >> > pulseaudio-discuss mailing list >> > pulseaudio-discuss@lists.freedesktop.org >> > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss >> >> >> >> -- >> Alexander E. Patrakov -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] format: Fix rate for HBR passthrough formats
There is some Microsoft documentation that contradicts this code. https://msdn.microsoft.com/en-us/library/windows/desktop/dd316761(v=vs.85).aspx """ Dolby TrueHD (MAT) Dolby TrueHD content is transmitted over IEC 60958 at 176.4 kHz / 8 channels (requiring an IEC 60958 frame rate of 705.6 kHz) for content sample rates of 44.1, 88.2 and 176.4 kHz, and 192 kHz / 8 channels (requiring an IEC 60958 frame rate of 768 kHz) for content sample rates of 48, 96 and 192 kHz. """ 2018-05-22 12:13 GMT+08:00 Arun Raghavan <a...@arunraghavan.net>: > In high bitrate mode, we force 192kHz/8ch as the sample format, which is > the expectation for HBR formats (as that is what allows for the largest > possible packet size). > --- > src/pulsecore/core-format.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/pulsecore/core-format.c b/src/pulsecore/core-format.c > index 862a74b5d..096acc3a2 100644 > --- a/src/pulsecore/core-format.c > +++ b/src/pulsecore/core-format.c > @@ -248,6 +248,9 @@ int pa_format_info_to_sample_spec_fake(const > pa_format_info *f, pa_sample_spec * > > if (f->encoding == PA_ENCODING_EAC3_IEC61937) > ss->rate *= 4; > +else if ((f->encoding == PA_ENCODING_TRUEHD_IEC61937) || > + (f->encoding == PA_ENCODING_DTSHD_IEC61937)) > +ss->rate = 192000; > > return 0; > } > -- > 2.17.0 > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2] alsa-sink/source: always set reconfiguration callback
Looks good to me.
2018-04-28 0:07 GMT+08:00 Sangchul Lee <sangchul1...@gmail.com>:
> From: Sangchul Lee <sangchul1...@gmail.com>
>
> Reconfiguration callback should also be set in case of avoiding resampling
> option. This patch set the callback for every case because the callback
> has already conditions to leave if it is not needed.
> Also unnecessary codes of setting alternate sample rate to 0 are removed.
>
> Signed-off-by: Sangchul Lee <sc11@samsung.com>
> ---
> src/modules/alsa/alsa-sink.c | 3 +--
> src/modules/alsa/alsa-source.c | 3 +--
> src/pulsecore/sink.c | 9 ++---
> src/pulsecore/source.c | 9 ++---
> 4 files changed, 6 insertions(+), 18 deletions(-)
>
> diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
> index afdf813..4568a19 100644
> --- a/src/modules/alsa/alsa-sink.c
> +++ b/src/modules/alsa/alsa-sink.c
> @@ -2434,8 +2434,7 @@ pa_sink *pa_alsa_sink_new(pa_module *m, pa_modargs *ma,
> const char*driver, pa_ca
> u->sink->set_port = sink_set_port_ucm_cb;
> else
> u->sink->set_port = sink_set_port_cb;
> -if (u->sink->alternate_sample_rate)
> -u->sink->reconfigure = sink_reconfigure_cb;
> +u->sink->reconfigure = sink_reconfigure_cb;
> u->sink->userdata = u;
>
> pa_sink_set_asyncmsgq(u->sink, u->thread_mq.inq);
> diff --git a/src/modules/alsa/alsa-source.c b/src/modules/alsa/alsa-source.c
> index 73c2a25..8014bc0 100644
> --- a/src/modules/alsa/alsa-source.c
> +++ b/src/modules/alsa/alsa-source.c
> @@ -2110,8 +2110,7 @@ pa_source *pa_alsa_source_new(pa_module *m, pa_modargs
> *ma, const char*driver, p
> u->source->set_port = source_set_port_ucm_cb;
> else
> u->source->set_port = source_set_port_cb;
> -if (u->source->alternate_sample_rate)
> -u->source->reconfigure = source_reconfigure_cb;
> +u->source->reconfigure = source_reconfigure_cb;
> u->source->userdata = u;
>
> pa_source_set_asyncmsgq(u->source, u->thread_mq.inq);
> diff --git a/src/pulsecore/sink.c b/src/pulsecore/sink.c
> index b801b6b..38e8e50 100644
> --- a/src/pulsecore/sink.c
> +++ b/src/pulsecore/sink.c
> @@ -271,11 +271,6 @@ pa_sink* pa_sink_new(
> else
> s->alternate_sample_rate = s->core->alternate_sample_rate;
>
> -if (s->sample_spec.rate == s->alternate_sample_rate) {
> -pa_log_warn("Default and alternate sample rates are the same.");
> -s->alternate_sample_rate = 0;
> -}
> -
> s->inputs = pa_idxset_new(NULL, NULL);
> s->n_corked = 0;
> s->input_to_master = NULL;
> @@ -1500,9 +1495,9 @@ int pa_sink_reconfigure(pa_sink *s, pa_sample_spec
> *spec, bool passthrough) {
> default_rate_is_usable = true;
> if (default_rate % 4000 == 0 && spec->rate % 4000 == 0)
> default_rate_is_usable = true;
> -if (alternate_rate && alternate_rate % 11025 == 0 && spec->rate %
> 11025 == 0)
> +if (alternate_rate % 11025 == 0 && spec->rate % 11025 == 0)
> alternate_rate_is_usable = true;
> -if (alternate_rate && alternate_rate % 4000 == 0 && spec->rate %
> 4000 == 0)
> +if (alternate_rate % 4000 == 0 && spec->rate % 4000 == 0)
> alternate_rate_is_usable = true;
>
> if (alternate_rate_is_usable && !default_rate_is_usable)
> diff --git a/src/pulsecore/source.c b/src/pulsecore/source.c
> index ffb8b6c..02ae87a 100644
> --- a/src/pulsecore/source.c
> +++ b/src/pulsecore/source.c
> @@ -258,11 +258,6 @@ pa_source* pa_source_new(
> else
> s->alternate_sample_rate = s->core->alternate_sample_rate;
>
> -if (s->sample_spec.rate == s->alternate_sample_rate) {
> -pa_log_warn("Default and alternate sample rates are the same.");
> -s->alternate_sample_rate = 0;
> -}
> -
> s->outputs = pa_idxset_new(NULL, NULL);
> s->n_corked = 0;
> s->monitor_of = NULL;
> @@ -1081,9 +1076,9 @@ int pa_source_reconfigure(pa_source *s, pa_sample_spec
> *spec, bool passthrough)
> default_rate_is_usable = true;
> if (default_rate % 4000 == 0 && spec->rate % 4000 == 0)
> default_rate_is_usable = true;
> -if (alternate_rate && alternate_rate % 11025 == 0 && spec->rate %
> 11025 == 0)
> +if (alternate_rate % 11025 == 0 && spec->rate % 11025 == 0)
> alternate_rate_i
Re: [pulseaudio-discuss] Non-working microphone on Logtech HD Pro Webcam C920
Please run: alsamixer -c C920, then press F4 and post a screenshot. 2018-03-08 12:39 GMT+08:00 Brandon Carpenter <elementary.eni...@gmail.com>: > On Wed, Mar 7, 2018 at 8:02 PM Alexander E. Patrakov <patra...@gmail.com> > wrote: >> Please run "alsa-info.sh". It will create a URL with more details. Post > it here. > > Here is the requested URL. > > http://www.alsa-project.org/db/?f=becec9bdf57140051b79a004defd919413396342 > > Thank you. > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Non-working microphone on Logtech HD Pro Webcam C920
2018-03-08 8:43 GMT+08:00 Brandon Carpenter <elementary.eni...@gmail.com>: > Dear PulseAudio experts, > > I just setup Arch Linux on a new Dell Precision 5520 laptop and, because the > built-in "nose-cam" is positioned under the display, I am using a new > Logitech HD Pro Webcam C920. The camera on the C920 works flawlessly. > However, the builtin microphone only worked occasionally, and recently > stopped working altogether. Please run "alsa-info.sh". It will create a URL with more details. Post it here. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/3] alsa: fix infinite loop with Intel HDMI LPE
2017-12-29 20:37 GMT+08:00 Tanu Kaskinen <ta...@iki.fi>: > On Fri, 2017-12-29 at 11:46 +0800, Alexander E. Patrakov wrote: >> 2017-12-28 18:09 GMT+08:00 Tanu Kaskinen <ta...@iki.fi>: >> > The Intel HDMI LPE driver works in a peculiar way when the HDMI cable is >> > not plugged in: any written audio is immediately discarded and underrun >> > is reported. That resulted in an infinite loop, because PulseAudio tried >> > to keep the buffer filled, which was futile since the written audio was >> > immediately consumed/discarded. >> > >> > This patch adds special handling for the LPE driver: if the active port >> > of the sink is unavailable, the sink suspends itself. A new suspend >> > cause is added: PA_SUSPEND_UNAVAILABLE. >> >> I think this is not a complete fix. There was a case in the past where >> some other card started eating samples too quickly (some Radeon? >> unfortunately, can't find it now). While blacklisting one known bad >> driver helps, I think it would be better to detect the misbehavior at >> runtime, based on the number of samples written and the wall-clock >> time. If the card stalls or eats samples too quickly, set a flag that >> it misbehaves, accept the xrun, and then set it to off when >> convenient. >> >> Sorry, I have no time to help with the code :( > > Did that other sample-eating sound card exhibit the behaviour only when > unplugged? With the LPE driver we know that we can resume once the > cable is plugged in again. If we don't take the jack state into > consideration, then we don't know when we should try resuming. Yes, it was only when unplugged. The thread (found it!) starts here: http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/081365.html David: do you know whether it has been fixed in the kernel in that case? > I can change the patch so that the sink is suspended when both of the > conditions are fulfilled: too fast sample consumption and jack > unplugged. I think an "or" condition would be more appropriate here, for robustness. The real bug here is the CPU overuse (in the worst case, infinite loop) due to too-fast sample consumption by a misbehaving soundcard driver (but we accept that this misbehavior happens and we have to deal with it). The fact that the cable is unplugged is just one known trigger. But, it's up to you to decide. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 1/3] alsa: fix infinite loop with Intel HDMI LPE
2017-12-28 18:09 GMT+08:00 Tanu Kaskinen <ta...@iki.fi>: > The Intel HDMI LPE driver works in a peculiar way when the HDMI cable is > not plugged in: any written audio is immediately discarded and underrun > is reported. That resulted in an infinite loop, because PulseAudio tried > to keep the buffer filled, which was futile since the written audio was > immediately consumed/discarded. > > This patch adds special handling for the LPE driver: if the active port > of the sink is unavailable, the sink suspends itself. A new suspend > cause is added: PA_SUSPEND_UNAVAILABLE. I think this is not a complete fix. There was a case in the past where some other card started eating samples too quickly (some Radeon? unfortunately, can't find it now). While blacklisting one known bad driver helps, I think it would be better to detect the misbehavior at runtime, based on the number of samples written and the wall-clock time. If the card stalls or eats samples too quickly, set a flag that it misbehaves, accept the xrun, and then set it to off when convenient. Sorry, I have no time to help with the code :( -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to setup developer environment to develop pulseaudio modules?
2017-10-17 16:03 GMT+05:00 <namit...@codeaurora.org>:
> I using ubuntu 14.04 and pulseaudio 4.0. I am compiling very simple test
> module, module-test.c
>
> #include
>
> int pa__init(pa_module* m){
> return 0;
> }
>
> when i try to compile it using
>
> gcc -g -shared -o module-test.so module-test.c
>
> i get this error
>
> module-test.c:1:30: fatal error: pulsecore/module.h: No such file or
> directory
> #include
> ^
> compilation terminated.
>
> i looked in /usr/include and there is no folder name pulsecore. i tried
> installing development packages like libpulse-dev but that didn't solve this
> issue.
Hello.
The real issue is that external modules are currently not supported at
all. So - please clone pulseaudio git, and create your module there.
You will not be able to load it into a distribution-provided
pulseaudio.
In other words, modules are used by PulseAudio not as an "extension
point for third parties like you", but as a convenience for
distributors so that they can split the package and do not require
libraries that are needed only for rare cases to be installed by
default.
--
Alexander E. Patrakov
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Bass management
2017-09-22 22:12 GMT+05:00 Christian Weinz <christ...@madez.de>: > Hello, > > I use headphones, and have tactile transducers on my chair. This makes > the audio sound louder and feel more intense. This is good for my ears > and my neighbours. > > This setup requires 2.1 output. I tried the GNOME-Settings to set the > output to 2.1. That option was not available. I also tried alsamixer, > paprefs and pavucontrol, to no avail. I played around with > hdajackretask, and finally, after overriding both the Pink Mic port to > Center/LFE and the Blue Line In to Back, I can select 2.1 audio in the > GNOME-Settings. This was difficult to setup. > > Then, however, I had the full-range signal on both my headphones and on > the synthesized LFE channel. This means I hear voices in my chair. To > prevent that, I set the lfe-crossover frequency, but then I lose the > bass in my headphones. Both is bad. Thank you for accurately describing the frequency responses both of the headphones and the transducer. In particular, for confirmation that there is a significant overlap, which is the necessary condition to make sure that what we'll design will work not only for your hardware. > Now I found the patch "Add option to disable highpass-filter on non-lfe > channels." by Markus Ebner at > > https://pw-emeril.freedesktop.org/patch/171424/ > > This patch, if it works at advertised, would solve my problem. But the > patch was rejected. I would comment there, but because the websites > certificate is invalid, I cannot create an account to comment, since > Google's reCAPTCHA refuses to work. > > To summarize, for my setup I need the full-range stereo signal on my > headphones and a low-pass filtered LFE signal for the transducers. Is > there a way to do this with PulseAudio? The patch will not solve your problem acceptably, because the low frequencies from the headphones and the transducer will not be in-phase, due to the delay created by the filter. I think (but am not sure, input from other DSP experts is welcome) that the following is better than the approach in the original patch: 1. Apply a lowpass filter, in the form of two cascaded 2nd order Butterworth filters, to each channel. Store the result. 2. Apply a matching highpass filter, in the form of two cascaded 2nd order Butterworth filters, to each channel. Also store the result. 3. Send the sum of low frequencies (as stored on step 1) for each input channel, appropriately scaled, to the LFE channel. 4. For each non-LFE input channel, add low frequencies extracted during step 1 to high frequencies extracted during step 2. Send the result to the corresponding output. Note: step 4 does not reproduce the original waveform. What you get is an "allpass filter", which changes phase (so that it matches what we send to the LFE channel), but not amplitude. > To add on this question, my Denon AVR X3100W has individual cut-off > frequencies for each channel, and the subwoofer has its own low-pass > frequency. How can I have this fine-grained control with PulseAudio? We need to reverse-engineer the kind of filtering that they use and try to find justification, or conditions when it is valid. As I said, naive attempts of attaching independently-tuned filters to each channel are Just Wrong from the DSP viewpoint, because of phase. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RAOP] [PATCH] Fix audio synchronisation
On 09/06/2017 12:16 AM, Colin Leroy wrote: - Audacity works - mPlayer and mpv work - Parole works - Totem works - Rhythmbox works Basically it seems only VLC tries to sync audio to video instead of the contrary :) That's with the default settings. Please read about the --video-sync=... option of mpv. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [RFC PATCH 0/2] HDMI IEC61937 + HBR passthrough support
2017-08-29 3:49 GMT+05:00 Pierre-Louis Bossart <pierre-louis.boss...@linux.intel.com>: > HDMI passthrough needs some love. What works with ALSA is plain > broken with PulseAudio (no audio or random noise). Only the AC3 > format seems to work, EAC3 is broken and HBR formats are not > supported yet. > > Fix EAC3 issues where the AES non-audio bit is not set when opening > the alsa-sink. The fix is to force a suspend/resume when an actual > sink-input is connected. This is far from optimal since we suspend/resume > twice (once for rate, once on entering passthrough) but the state > machine is obviously quite racy. > > Add definitions for Dolby TrueHD and DTSHD. This needs additional > work since ALSA will only enable the HBR passthrough mode with > 8 channels and 192kHz. For now the ALSA sinks are only configured to > support 2 channels for passthrough and we'd need to switch between 2 > and 8 channels depending on the format. I don't quite understand how > the profiles are managed and could use some help here. Your work invalidates the comment added in this commit: https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=04737989ec537e01d63c155807a5d19b0ec5b294 I think that, if you don't undo this commit, at least a better message what exactly works is needed. I.e. how to test, given that the HDMI sink does not have the formats set. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] configuring pulseaudio as backend for Qemu
2017-08-17 17:20 GMT+05:00 Sameeh Jubran <sam...@daynix.com>: > Hi all, > > I am trying to set pulseaudio as a backend for qemu with intel hda virtual > sound card. I can't seem to configure pulseaudio correctly due sudo > privileges mismatch, I run Qemu with sudo but when I attempt to run > pulseaudio with sudo I can't hear anything. Is there any detailed tutorial > on how to accomplish this? Why do you run qemu with sudo? This should not be needed. If this is due to the graphics card pass-through, try to chown the vfio nodes to your user instead. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] Add option to disable highpass-filter on non-lfe channels.
2017-08-12 0:27 GMT+05:00 Markus Ebner <markus-eb...@web.de>:
> On 08/11/2017 06:51 PM, Alexander E. Patrakov wrote:
>>
>> 2017-08-11 21:48 GMT+05:00 Alexander E. Patrakov <patra...@gmail.com>:
>>>
>>> 2017-08-10 1:27 GMT+05:00 Markus Ebner <markus-eb...@web.de>:
>>>>
>>>> Added a new configuration option: remix-non-lfe-channels (default: yes),
>>>> which results in the non-lfe channels being highpass-filtered.
>>>> When set to false, the lfe channel is lowpass-filtered and the other
>>>> channels stay untouched.
>>>> Removing the low frequencies from speakers that support low frequencies
>>>> sounds awful.
>>>> The current behavior is the default, since this case is less likely than
>>>> speakers not playing well with low frequencies.
>>>
>>> I tend to reject the patch. In the use case with satellite speakers
>>> that are able to reproduce low frequencies, enabling LFE remixing (and
>>> thus the filter) is a user error.
>>
>> Also, the highpass filter on non-lfe channels was designed to filter
>> out exactly the same frequencies that were sent from the main channels
>> to LFE. I.e. "moved". With your patch, they will be "duplicated",
>> which is wrong.
>>
>>
> I'm not that knowledgeable regarding audio, so my reply represents what I
> think I know of the subject.
>
> I am not quite sure what the problem is. In the Computer Graphics field, the
> simple principle is: All's well that looks well.
> I thought that the same applied to audio. As long as it sounds good, why
> bother with the details?
>
> Most "cheap" 5.1 computer speakers exist of
> - 4 satellites (high to maybe center frequencies)
> - 1 center (center frequencies)
> - 1 subwoofer (low frequenciesa)
>
> Pulseaudio's lfe remix in its current form does exactly what is best for
> this setup, since only the subwoofer is able to represent low frequencies.
Well, except for the scaling factor for the audio moved into the
subwoofer. That's a known bug, but nobody among devs knows what's
correct.
> Whereas the satellites of high-class speaker-setups (like the "Teufel
> Theater 500 Surround 5.1 Set") support the full spectrum of frequencies.
> The satellite of the above mentioned setup ("Tower Speaker T 500 F 16") has
> dedicated woofers inside.
> And if I haven't made a mistake, driving this setup with the lfe-remix
> enabled will result in the towers' woofers to effectively be disabled.
> Why would I pay 1700€ for a high-class setup if I can't properly drive its
> speakers?
Correct. The question is, again: why does one want lfe-remix enabled
in such setup?
You either want to reproduce low frequencies with woofers inside
satellites, or to move them to the subwoofer. But note that there is
no sharp transition between them, and that's important.
> Sure, this particular setup probably has an analog frequency-separation
> filter inside the subwoofer, but there are setups that haven't. In such a
> setup (without filter), disabling the lfe-remixer will lead to the subwoofer
> playing the whole frequency spectrum - which isn't that good of an idea. And
> not all analog filters are better than pulseaudios' (We tested a couple).
>
> Our particular setup is:
> - 2 x the box CL 110 Top MK II (90 - 19000Hz)
> - 1 x custom made subwoofer (without an analog frequency filter inside) (20
> - 140Hz)
> Comparing the unpatched pulseaudio (lfe remix on/off) does not sound good,
> while with the patch, it sounds much better (on).
If this is reproducible with a non-custom subwoofer (in a whole system
that passed the sales person approval and was tested with a non-PC
signal source), I accept the bug report, but not the solution. In this
custom case, I would call it a subwoofer design error. In other words,
if the system cannot be configured to sound well with an off-the-shelf
receiver (such as Onkyo TX-NR 636, which does not support filtering
only the subwoofer), I see no point in supporting it with PulseAudio.
Basically, no matter how good the separation filter is, there is a
frequency band (in PulseAudio's LR4 filter, that's approximately two
octaves) where the signal is reproduced both by the satellites and the
subwoofer. In this overlap area, the satellites and the subwoofer must
sound exactly(*) in-phase. That's why matching filters are required,
so that the delay introduced by them always differs by 360 degrees of
phase. And in this overlap area, in a good system, nether the
satellites nor the subwoofer must display any response roll-off or
changing phase delays. So the woofers inside satellites are indeed
properly driven even if LFE remixing is enabled.
(*) The "exac
Re: [pulseaudio-discuss] [PATCH] scripts: Add a pre-receive hook to catch invalid merge and WIP commits
2017-04-07 12:03 GMT+05:00 Arun Raghavan <a...@arunraghavan.net>: > +#!/usr/bin/env python On some distributions that's python2, and on some it's python3. Please be specific. > +if error_badcommon: > +print " Attempting to push commits containing modifications to > common" > +print " that have not been commited to the actuall common module." > +print > +print " First push your changes to common/ before pushing the > changes" > +print " to the module using it." I believe this doesn't apply to pulseaudio. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] problem with webrtc and pulseaudio
2017-02-14 23:13 GMT+05:00 Fatima Castiglione Maldonado 发 <castiglionemaldon...@gmail.com>: > it did not work > maybe module is not installed? It is too old to accept arguments that I specified. Try without them: pacmd load-module module-echo-cancel -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] problem with webrtc and pulseaudio
2017-02-14 19:21 GMT+05:00 Fatima Castiglione Maldonado 发 <castiglionemaldon...@gmail.com>: >> What does "broken" mean more specifically? Things appear to work, but >> the microphone produces just silence? >> > The mic produces a very distorted sound, like "cracking" sound As a temporary workaround, you can run "pacmd load-module module-echo-cancel channels=2 rate=48000 use_master_format=true", and then, using pavucontrol, move Chrome's input and output to echo-cancelled devices. That just exploits the fact that virtual sinks behave differently than normal ones in aspects related to buffering. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] bluetooth: Make use of getsockopt() configurable
> +if (pa_modargs_get_value_boolean(ma, "use_getsockopt", _getsockopt)
> < 0) {
> +pa_log("Invalid boolean value for use_getsockopt parameter");
> +goto fail_free_modargs;
> +}
> +
> +u->device->use_getsockopt = use_getsockopt;
> +
> pa_modargs_free(ma);
>
> u->device_connection_changed_slot =
> diff --git a/src/modules/bluetooth/module-bluez5-discover.c
> b/src/modules/bluetooth/module-bluez5-discover.c
> index 080e5d0..d49e960 100644
> --- a/src/modules/bluetooth/module-bluez5-discover.c
> +++ b/src/modules/bluetooth/module-bluez5-discover.c
> @@ -42,6 +42,7 @@ PA_MODULE_USAGE(
>
> static const char* const valid_modargs[] = {
> "headset",
> +"use_getsockopt",
> NULL
> };
>
> @@ -51,6 +52,7 @@ struct userdata {
> pa_hashmap *loaded_device_paths;
> pa_hook_slot *device_connection_changed_slot;
> pa_bluetooth_discovery *discovery;
> +bool use_getsockopt;
> };
>
> static pa_hook_result_t device_connection_changed_cb(pa_bluetooth_discovery
> *y, const pa_bluetooth_device *d, struct userdata *u) {
> @@ -71,7 +73,7 @@ static pa_hook_result_t
> device_connection_changed_cb(pa_bluetooth_discovery *y,
> if (!module_loaded && pa_bluetooth_device_any_transport_connected(d)) {
> /* a new device has been connected */
> pa_module *m;
> -char *args = pa_sprintf_malloc("path=%s", d->path);
> +char *args = pa_sprintf_malloc("path=%s use_getsockopt=%i", d->path,
> (int)u->use_getsockopt);
>
> pa_log_debug("Loading module-bluez5-device %s", args);
> m = pa_module_load(u->module->core, "module-bluez5-device", args);
> @@ -101,6 +103,7 @@ int pa__init(pa_module *m) {
> pa_modargs *ma;
> const char *headset_str;
> int headset_backend;
> +bool use_getsockopt;
>
> pa_assert(m);
>
> @@ -121,9 +124,16 @@ int pa__init(pa_module *m) {
> goto fail;
> }
>
> +use_getsockopt = false;
> +if (pa_modargs_get_value_boolean(ma, "use_getsockopt", _getsockopt)
> < 0) {
> +pa_log("Invalid boolean value for use_getsockopt parameter");
> +goto fail;
> +}
> +
> m->userdata = u = pa_xnew0(struct userdata, 1);
> u->module = m;
> u->core = m->core;
> +u->use_getsockopt = use_getsockopt;
> u->loaded_device_paths = pa_hashmap_new(pa_idxset_string_hash_func,
> pa_idxset_string_compare_func);
>
> if (!(u->discovery = pa_bluetooth_discovery_get(u->core,
> headset_backend)))
> --
> 2.10.1
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
Alexander E. Patrakov
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] bluetooth latencies
I meant that these are latencies that are related to different parts
of the path.
Please send the patch, but I don't have the expertise to review it.
2017-01-30 22:46 GMT+05:00 Georg Chini <ge...@chini.tk>:
> On 30.01.2017 18:37, Alexander E. Patrakov wrote:
>>
>> I am not a bluetooth expert, but: is this a different latency? Maybe
>> the situation is that the headset has its own 28-ms buffer, and
>> PulseAudio adds 25 or 125 ms on top of that?
>
>
> What do you mean by different latency? The values are passed
> to pulse via pa_{sink, source}_set_fixed_latency_within_thread()
> (plus one write block size). So pulse reports 128 ms fixed latency
> for the SCO sink, while the current latency is around 28 ms.
>
>
>>
>> 2017-01-30 21:35 GMT+05:00 Georg Chini <ge...@chini.tk>:
>>>
>>> Hello,
>>>
>>> in module-bluez5-device.c and module-bluez4-device.c, latencies for
>>> bluetooth are defined as follows:
>>>
>>> #define FIXED_LATENCY_PLAYBACK_A2DP (25 * PA_USEC_PER_MSEC)
>>> #define FIXED_LATENCY_PLAYBACK_SCO (125 * PA_USEC_PER_MSEC)
>>> #define FIXED_LATENCY_RECORD_A2DP (25 * PA_USEC_PER_MSEC)
>>> #define FIXED_LATENCY_RECORD_SCO(25 * PA_USEC_PER_MSEC)
>>>
>>> Is the fixed latency for SCO playback a mistake? Both headsets I own
>>> report around 28 ms actual latency for the SCO sink, so I cannot
>>> understand why the fixed latency is set to 125 ms. Should I send a
>>> patch to correct it?
>>>
>>> Regards
>>> Georg
>>>
>>> ___
>>> pulseaudio-discuss mailing list
>>> pulseaudio-discuss@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>>
>>
>>
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
Alexander E. Patrakov
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] bluetooth latencies
I am not a bluetooth expert, but: is this a different latency? Maybe the situation is that the headset has its own 28-ms buffer, and PulseAudio adds 25 or 125 ms on top of that? 2017-01-30 21:35 GMT+05:00 Georg Chini <ge...@chini.tk>: > Hello, > > in module-bluez5-device.c and module-bluez4-device.c, latencies for > bluetooth are defined as follows: > > #define FIXED_LATENCY_PLAYBACK_A2DP (25 * PA_USEC_PER_MSEC) > #define FIXED_LATENCY_PLAYBACK_SCO (125 * PA_USEC_PER_MSEC) > #define FIXED_LATENCY_RECORD_A2DP (25 * PA_USEC_PER_MSEC) > #define FIXED_LATENCY_RECORD_SCO(25 * PA_USEC_PER_MSEC) > > Is the fixed latency for SCO playback a mistake? Both headsets I own > report around 28 ms actual latency for the SCO sink, so I cannot > understand why the fixed latency is set to 125 ms. Should I send a > patch to correct it? > > Regards > Georg > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] thread-test: fix deadlock
2017-01-23 13:38 GMT+05:00 Tanu Kaskinen <ta...@iki.fi>:
> If we set magic_number to zero, the code will deadlock, because the
> thread that is waiting for us to set magic_number to non-zero will
> never progress.
>
> The problem was reported here:
> https://lists.freedesktop.org/archives/pulseaudio-discuss/2017-January/027368.html
> ---
> src/tests/thread-test.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
I have looked at the fix and believe that it's correct.
>
> diff --git a/src/tests/thread-test.c b/src/tests/thread-test.c
> index 72f21770e..0c83e67e0 100644
> --- a/src/tests/thread-test.c
> +++ b/src/tests/thread-test.c
> @@ -115,7 +115,10 @@ START_TEST (thread_test) {
> for (k = 0; k < 100; k++) {
> pa_assert(magic_number == 0);
>
> -magic_number = (int) rand() % 0x1;
> +/* There's a thread waiting for us to change magic_number to a
> non-zero
> + * value. The "+ 1" part ensures that we don't accidentally set
> + * magic_number to zero here. */
> +magic_number = (int) rand() % 0x1 + 1;
>
> pa_log_info("iteration %i (%i)", k, magic_number);
>
> --
> 2.11.0
>
> ___
> pulseaudio-discuss mailing list
> pulseaudio-discuss@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
--
Alexander E. Patrakov
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] First draft of 10.0 release notes completed
Yes, I see the contradiction. Thanks for noticing it. Indeed, I have misremembered the forum post that prompted me to investigate the bug. In that forum post, the microphone actually worked, but the speakers didn't, because the device supports only multi-channel output. https://bugs.freedesktop.org/show_bug.cgi?id=54029 also talks about device that only supports multi-channel output. Anyway, even for stereo devices, there was a "Unable to find definition 'cards.USB-Audio.pcm.front:CARD=1'" error in the log and an unneeded fallback from front to hw. 2017-01-11 5:06 GMT+05:00 Tanu Kaskinen <ta...@iki.fi>: > On Tue, 2017-01-10 at 04:35 +0500, Alexander E. Patrakov wrote: >> 2017-01-09 1:05 GMT+05:00 Tanu Kaskinen <ta...@iki.fi>: >> > Hi all, >> > >> > The first draft of the 10.0 release notes is now complete: >> > https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/10.0/ >> > >> > If you think something should be added or removed or changed, please >> > reply to this mail or just edit the wiki. >> >> I think it should be mentioned that the long-standing bug with ALSA >> device hotplug has been fixed. >> >> https://bugs.freedesktop.org/show_bug.cgi?id=54029 >> >> This bug affected hot-plugging any USB microphone or non-stereo >> speakers, i.e. anything that uses ALSA device other than "hw:". > > Yes, mentioning that seems like a good idea. But first a request for > clarification: pulseaudio uses "hw:" for microphones, so your > description above seems contradictory. > > -- > Tanu > > https://www.patreon.com/tanuk > _______ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] First draft of 10.0 release notes completed
2017-01-09 1:05 GMT+05:00 Tanu Kaskinen <ta...@iki.fi>: > Hi all, > > The first draft of the 10.0 release notes is now complete: > https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/10.0/ > > If you think something should be added or removed or changed, please > reply to this mail or just edit the wiki. I think it should be mentioned that the long-standing bug with ALSA device hotplug has been fixed. https://bugs.freedesktop.org/show_bug.cgi?id=54029 This bug affected hot-plugging any USB microphone or non-stereo speakers, i.e. anything that uses ALSA device other than "hw:". -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 2/4] resampler: Flag for remixing to all sink channels.
2017-01-04 9:17 GMT+05:00 <da...@mandelberg.org>:
> From: David Mandelberg <dse...@google.com>
>
> Add a flag PA_RESAMPLER_USE_ALL_SINK_CHANNELS, which controls whether
> remixing should attempt to use all sink channels, versus only the ones
> needed to reproduce the source audio.
>
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=62588
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=94563
>
> Suggested-by: Alexander E. Patrakov <patra...@gmail.com>
> ---
> src/pulsecore/resampler.c | 82
> +--
> src/pulsecore/resampler.h | 4 ++-
> 2 files changed, 76 insertions(+), 10 deletions(-)
Objection here.
You have introduced a new flag, that has to be on by default in order
to preserve the old default behavior. But actually it is off by
default, and in patch 4 it is off by default.
All other flags in this group are off by default, and most of them are
named like PA_RESAMPLER_NO_*. So the suggestion here is to rename the
flag and invert its meaning, so that we can keep it off by default and
thus have PulseAudio fill all the output channels by default, like it
does now. Something like PA_RESAMPLE_NO_FILL.
I have not reviewed the code for other aspects of remixing.
>
> diff --git a/src/pulsecore/resampler.c b/src/pulsecore/resampler.c
> index ea22cd2..4feface 100644
> --- a/src/pulsecore/resampler.c
> +++ b/src/pulsecore/resampler.c
> @@ -796,6 +796,64 @@ static int front_rear_side(pa_channel_position_t p) {
> return ON_OTHER;
> }
>
> +/* Fill a map of which output channels should get mono from input, not
> including
> + * LFE output channels. (The LFE output channels are mapped separately.)
> + */
> +static void setup_oc_mono_map(const pa_resampler *r, float *oc_mono_map) {
> +unsigned oc;
> +unsigned n_oc;
> +bool found_oc_for_mono = false;
> +
> +pa_assert(r);
> +pa_assert(oc_mono_map);
> +
> +n_oc = r->o_ss.channels;
> +
> +if (r->flags & PA_RESAMPLER_USE_ALL_SINK_CHANNELS) {
> +/* Mono goes to all non-LFE output channels and we're done. */
> +for (oc = 0; oc < n_oc; oc++)
> +oc_mono_map[oc] = on_lfe(r->o_cm.map[oc]) ? 0.0f : 1.0f;
> +return;
> +} else {
> +/* Initialize to all zero so we can select individual channels
> below. */
> +for (oc = 0; oc < n_oc; oc++)
> +oc_mono_map[oc] = 0.0f;
> +}
> +
> +for (oc = 0; oc < n_oc; oc++) {
> +if (r->o_cm.map[oc] == PA_CHANNEL_POSITION_MONO) {
> +oc_mono_map[oc] = 1.0f;
> +found_oc_for_mono = true;
> +}
> +}
> +if (found_oc_for_mono)
> +return;
> +
> +for (oc = 0; oc < n_oc; oc++) {
> +if (r->o_cm.map[oc] == PA_CHANNEL_POSITION_FRONT_CENTER) {
> +oc_mono_map[oc] = 1.0f;
> +found_oc_for_mono = true;
> +}
> +}
> +if (found_oc_for_mono)
> +return;
> +
> +for (oc = 0; oc < n_oc; oc++) {
> +if (r->o_cm.map[oc] == PA_CHANNEL_POSITION_FRONT_LEFT ||
> r->o_cm.map[oc] == PA_CHANNEL_POSITION_FRONT_RIGHT) {
> +oc_mono_map[oc] = 1.0f;
> +found_oc_for_mono = true;
> +}
> +}
> +if (found_oc_for_mono)
> +return;
> +
> +/* Give up on finding a suitable map for mono, and just send it to all
> + * non-LFE output channels.
> + */
> +for (oc = 0; oc < n_oc; oc++)
> +oc_mono_map[oc] = on_lfe(r->o_cm.map[oc]) ? 0.0f : 1.0f;
> +}
> +
> static void setup_remap(const pa_resampler *r, pa_remap_t *m, bool
> *lfe_remixed) {
> unsigned oc, ic;
> unsigned n_oc, n_ic;
> @@ -858,14 +916,14 @@ static void setup_remap(const pa_resampler *r,
> pa_remap_t *m, bool *lfe_remixed)
> * 1) Connect all channels with matching names.
> *
> * 2) Mono Handling:
> - *S:Mono: Copy into all D:channels
> + *S:Mono: See setup_oc_mono_map().
> *D:Mono: Avg all S:channels
> *
> - * 3) Mix D:Left, D:Right:
> + * 3) Mix D:Left, D:Right (PA_RESAMPLER_USE_ALL_SINK_CHANNELS only):
> *D:Left: If not connected, avg all S:Left
> *D:Right: If not connected, avg all S:Right
> *
> - * 4) Mix D:Center
> + * 4) Mix D:Center (PA_RESAMPLER_USE_ALL_SINK_CHANNELS only):
> *If not connected, avg all S:Center
> *If still not connected, avg all S:Left, S:Right
> *
> @@ -908,6 +966,7 @@ static void setup_remap(const pa_resampler *r, pa_remap_t
> *m, bool *lfe_remixed)
>
Re: [pulseaudio-discuss] upmix and downmix values for enable-remixing?
Hello David, there was some discussion on this topic in these existing bugs: https://bugs.freedesktop.org/show_bug.cgi?id=62588 https://bugs.freedesktop.org/show_bug.cgi?id=94563 2016-12-14 5:23 GMT+05:00 David Mandelberg <da...@mandelberg.org>: > Hi, > > I'd like to have a way to downmix sources that have more channels than > my sink, but never upmix sources with fewer channels. So I was thinking > of writing a patch to add "upmix" and "downmix" as valid values to the > enable-remixing option. Is that a good idea? (Also, apologies if this > has been discussed before. I did some searching and did not find > anything relevant.) > > -- > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ > > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] raop: add compatibility with openssl 1.1.0
2016-09-10 18:39 GMT+05:00 Tanu Kaskinen <ta...@iki.fi>: > I have tested that this builds with old and new openssl, but I have not > tested that the code works. I don't have any RAOP hardware. I think that you have an Android phone. In this case, please use this for testing: http://forum.xda-developers.com/showthread.php?p=29986442 (download attachment, because the app is no longer on Google Play) -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 2/3] core, device-port: check availability when choosing the default device
08.09.2016 16:06, Tanu Kaskinen wrote: It doesn't make sense to use a sink or source whose active port is unavailable, so let's take this into account when choosing the default sink and source. What happens if there is exactly one sink (e.g. desktop with just one sound card that has line output), and its active port becomes unavailable? -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 0/2] v9.0: Fix valgrind warnings
18.06.2016 00:53, Ahmed S. Darwish пишет: Hi, This mini patch series fixes the valgrind warnings earlier reported by Alexander here: http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/26105 They are generated over 'master' -- hopefully be merged there, if everything is OK, before the v9.0 release. There are no uninitialised value warnings with these patches. Thanks! -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Valgrind warnings, again
12.06.2016 21:39, Alexander E. Patrakov пишет: I have spent more time running pulseaudio (master + Tanu's patches) under valgrind today. This set of warnings has already been reported, and they appear every time PulseAudio is started: ==15442== Conditional jump or move depends on uninitialised value(s) ==15442==at 0x5C91288: shm_attach (shm.c:380) ==15442==by 0x5C91B68: pa_shm_cleanup (shm.c:453) ==15442==by 0x5C91D4C: sharedmem_create (shm.c:150) ==15442==by 0x5C91D4C: pa_shm_create_rw (shm.c:239) ==15442==by 0x5C82193: pa_mempool_new (memblock.c:848) ==15442==by 0xF245FF7: setup_srbchannel (protocol-native.c:2634) ==15442==by 0xF245FF7: command_auth (protocol-native.c:2864) ==15442==by 0x5C8989E: pa_pdispatch_run (pdispatch.c:346) ==15442==by 0xF2486C4: pstream_packet_callback (protocol-native.c:4989) ==15442==by 0x5C8C216: do_read (pstream.c:987) ==15442==by 0x5C8EEF3: do_pstream_read_write (pstream.c:227) ==15442==by 0x510040B: dispatch_pollfds (mainloop.c:655) ==15442==by 0x510040B: pa_mainloop_dispatch (mainloop.c:898) ==15442==by 0x510080B: pa_mainloop_iterate (mainloop.c:929) ==15442==by 0x51008AF: pa_mainloop_run (mainloop.c:944) ==15442== ==15442== Conditional jump or move depends on uninitialised value(s) ==15442==at 0x5C8C91D: pa_cmsg_ancil_data_close_fds (pstream.c:193) ==15442==by 0x5C8DE57: do_write (pstream.c:759) ==15442==by 0x5C8EEB7: do_pstream_read_write (pstream.c:233) ==15442==by 0x510040B: dispatch_pollfds (mainloop.c:655) ==15442==by 0x510040B: pa_mainloop_dispatch (mainloop.c:898) ==15442==by 0x510080B: pa_mainloop_iterate (mainloop.c:929) ==15442==by 0x51008AF: pa_mainloop_run (mainloop.c:944) ==15442==by 0x406E3B: main (main.c:1141) ==15442== ==15442== Conditional jump or move depends on uninitialised value(s) ==15442==at 0x5C8C91D: pa_cmsg_ancil_data_close_fds (pstream.c:193) ==15442==by 0x5C8CA90: item_free (pstream.c:371) ==15442==by 0x5C8DDC2: do_write (pstream.c:775) ==15442==by 0x5C8EEB7: do_pstream_read_write (pstream.c:233) ==15442==by 0x510040B: dispatch_pollfds (mainloop.c:655) ==15442==by 0x510040B: pa_mainloop_dispatch (mainloop.c:898) ==15442==by 0x510080B: pa_mainloop_iterate (mainloop.c:929) ==15442==by 0x51008AF: pa_mainloop_run (mainloop.c:944) ==15442==by 0x406E3B: main (main.c:1141) Bisected these (kind-of). If we use "exactly zero valgrind warnings" as the definition of good, then the first bad commit is: commit 73e86b1cb164b1c37b27238b529879a4a2d9f24c Author: Ahmed S. Darwish <darwish...@gmail.com> Date: Sun Mar 13 01:04:18 2016 +0200 pulsecore: Introduce memfd support Memfd is a simple memory sharing mechanism, added by the systemd/kdbus developers, to share pages between processes in an anonymous, no global registry needed, no mount-point required, relatively secure, manner. This patch introduces the necessary building blocks for using memfd shared memory transfers in PulseAudio. Memfd support shall also help us in laying out the necessary (but not yet sufficient) groundwork for application sandboxing, protecting PA from its clients, and protecting clients data from each other. We plan to exclusively use memfds, instead of POSIX SHM, on the way forward. Signed-off-by: Ahmed S. Darwish <darwish...@gmail.com> However, during the bisect, there were points with 0, 1, 2, and all 3 valgrind warnings, which means we may have 3 separate issues here. Ahmed, could you please look at the issues? Maybe the difference is that I am running valgrind as follows: valgrind --trace-children=yes ./src/pulseaudio -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Valgrind warnings, again
16.06.2016 13:43, Ahmed S. Darwish пишет: Hi :-) On Sun, Jun 12, 2016 at 09:39:17PM +0500, Alexander E. Patrakov wrote: I have spent more time running pulseaudio (master + Tanu's patches) under valgrind today. This set of warnings has already been reported, and they appear every time PulseAudio is started: ==15442== Conditional jump or move depends on uninitialised value(s) ==15442==at 0x5C91288: shm_attach (shm.c:380) ==15442==by 0x5C91B68: pa_shm_cleanup (shm.c:453) ==15442==by 0x5C91D4C: sharedmem_create (shm.c:150) ==15442==by 0x5C91D4C: pa_shm_create_rw (shm.c:239) ==15442==by 0x5C82193: pa_mempool_new (memblock.c:848) ==15442==by 0xF245FF7: setup_srbchannel (protocol-native.c:2634) ==15442==by 0xF245FF7: command_auth (protocol-native.c:2864) ==15442==by 0x5C8989E: pa_pdispatch_run (pdispatch.c:346) ==15442==by 0xF2486C4: pstream_packet_callback (protocol-native.c:4989) ==15442==by 0x5C8C216: do_read (pstream.c:987) ==15442==by 0x5C8EEF3: do_pstream_read_write (pstream.c:227) ==15442==by 0x510040B: dispatch_pollfds (mainloop.c:655) ==15442==by 0x510040B: pa_mainloop_dispatch (mainloop.c:898) ==15442==by 0x510080B: pa_mainloop_iterate (mainloop.c:929) ==15442==by 0x51008AF: pa_mainloop_run (mainloop.c:944) ==15442== Hmm .. the memfd patchset touched all the paths from do_pstream_read_write() upwards. Nonetheless, full valgrind checks was done back then without seeing any errors. [*] Do you see these warnings with memfds enabled or disabled? [*] https://goo.gl/Ls6gzJ (last row for the full valgrind command) I did not enable memfd at runtime and did not disable it at compile time. I think I'll bisect it later today or tomorrow. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 3/6] card: move profile selection after pa_card_new()
13.06.2016 01:36, Tanu Kaskinen пишет: On Sun, 2016-06-12 at 18:33 +0500, Alexander E. Patrakov wrote: 10.06.2016 22:55, Tanu Kaskinen пишет: I want module-alsa-card to set the availability of unavailable profiles before the initial card profile gets selected, so that the selection logic can use correct availability information. module-alsa-card initializes the jack state after calling pa_card_new(), however, and the profile selection happens in pa_card_new(). This patch solves that by moving parts of pa_card_new() to pa_card_choose_initial_profile() and pa_card_put(). pa_card_choose_initial_profile() applies the profile selection policy, so module-alsa-card can first call pa_card_new(), then initialize the jack state, and then call pa_card_choose_initial_profile(). After that module-alsa-card can still override the profile selection policy, in case module-alsa-card was loaded with the "profile" argument. Finally, pa_card_put() finalizes the card creation. An alternative solution would have been to move the jack initialization to happen before pa_card_new() and use pa_card_new_data instead of pa_card in the jack initialization code, but I disliked that idea (I want to get rid of the "new data" pattern eventually). The order in which the initial profile policy is applied is reversed in this patch. Previously the first one to set it won, now the last one to set it wins. I think this is better, because if you have N parties that want to set the profile, we avoid checking N times whether someone else has already set the profile. Looks OK to me, but I would like an extra confirmation whether in the UCM case the sequence of mixer accesses is the same before and after the patch. That's a pretty specific concern. What makes you concerned about the UCM case and not about the non-UCM case? Scratch that. It was based on my misunderstanding. I incorrectly thought that the patch changes the call chain that leads to card_set_profile(), and there is "if (u->use_ucm)" there. The new u->linked field guarantees that card_set_profile() is not called prematurely, so my concern was completely unfounded. The patch is OK. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 2/6] card: don't allow the CARD_NEW hook to fail
13.06.2016 01:12, Tanu Kaskinen пишет: I'd prefer to not add an assertion. Most of pa_hook_fire() calls in the code base don't check the return value, and none of the calls use an assertion. OK. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Valgrind warnings, again
pavucontrol (before PulseAudio has a chance to handle the connection): ==15374== Conditional jump or move depends on uninitialised value(s) ==15374==at 0x5C8C91D: pa_cmsg_ancil_data_close_fds (pstream.c:193) ==15374==by 0x5C8E193: do_write (pstream.c:792) ==15374==by 0x5C8EEB7: do_pstream_read_write (pstream.c:233) ==15374==by 0x510040B: dispatch_pollfds (mainloop.c:655) ==15374==by 0x510040B: pa_mainloop_dispatch (mainloop.c:898) ==15374==by 0x510080B: pa_mainloop_iterate (mainloop.c:929) ==15374==by 0x51008AF: pa_mainloop_run (mainloop.c:944) ==15374==by 0x406E3B: main (main.c:1141) ==15374== ==15374== Conditional jump or move depends on uninitialised value(s) ==15374==at 0x5C8C91D: pa_cmsg_ancil_data_close_fds (pstream.c:193) ==15374==by 0x5C8CA90: item_free (pstream.c:371) ==15374==by 0x5C8ECE5: pstream_free (pstream.c:386) ==15374==by 0x5C8ECE5: pa_pstream_unref (pstream.c:1145) ==15374==by 0x510040B: dispatch_pollfds (mainloop.c:655) ==15374==by 0x510040B: pa_mainloop_dispatch (mainloop.c:898) ==15374==by 0x510080B: pa_mainloop_iterate (mainloop.c:929) ==15374==by 0x51008AF: pa_mainloop_run (mainloop.c:944) ==15374==by 0x406E3B: main (main.c:1141) -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 6/6] alsa: set availability for (some) unavailable profiles
12.06.2016 19:16, Alexander E. Patrakov пишет: 10.06.2016 22:55, Tanu Kaskinen пишет: The alsa card hasn't so far set any availability for profiles. That caused an issue with some HDMI hardware: the sound card has two HDMI outputs, but only the second of them is actually usable. The unavailable port is marked as unavailable and the available port is marked as available, but this information isn't propagated to the profile availability. Without profile availability information, the initial profile policy picks the unavailable one, since it has a higher priority value. This patch adds simple logic for marking some profiles unavailable: if the profile only contains unavailable ports, the profile is unavailable too. This can be improved in the future so that if a profile contains sinks or sources that only contain unavailable ports, the profile should be marked as unavailable. Implementing that requires adding more information about the sinks and sources to pa_card_profile, however. BugLink: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8448 Looks OK to me, too. I was surprised that the only calls to pa_card_profile_set_available() were in bluez modules. Now all that remains is to test it with my hardware, I will do it a bit later. The patch series works here as advertised. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 6/6] alsa: set availability for (some) unavailable profiles
10.06.2016 22:55, Tanu Kaskinen пишет:
The alsa card hasn't so far set any availability for profiles. That
caused an issue with some HDMI hardware: the sound card has two HDMI
outputs, but only the second of them is actually usable. The
unavailable port is marked as unavailable and the available port is
marked as available, but this information isn't propagated to the
profile availability. Without profile availability information, the
initial profile policy picks the unavailable one, since it has a
higher priority value.
This patch adds simple logic for marking some profiles unavailable:
if the profile only contains unavailable ports, the profile is
unavailable too. This can be improved in the future so that if a
profile contains sinks or sources that only contain unavailable ports,
the profile should be marked as unavailable. Implementing that
requires adding more information about the sinks and sources to
pa_card_profile, however.
BugLink: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8448
Looks OK to me, too. I was surprised that the only calls to
pa_card_profile_set_available() were in bluez modules.
Now all that remains is to test it with my hardware, I will do it a bit
later.
--
Alexander E. Patrakov
---
src/modules/alsa/module-alsa-card.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/src/modules/alsa/module-alsa-card.c
b/src/modules/alsa/module-alsa-card.c
index 1976230..323e08a 100644
--- a/src/modules/alsa/module-alsa-card.c
+++ b/src/modules/alsa/module-alsa-card.c
@@ -366,6 +366,7 @@ static int report_jack_state(snd_mixer_elem_t *melem,
unsigned int mask) {
void *state;
pa_alsa_jack *jack;
struct temp_port_avail *tp, *tports;
+pa_card_profile *profile;
pa_assert(u);
@@ -426,6 +427,32 @@ static int report_jack_state(snd_mixer_elem_t *melem,
unsigned int mask) {
if (tp->avail == PA_AVAILABLE_NO)
pa_device_port_set_available(tp->port, tp->avail);
+/* Update profile availabilities. The logic could be improved; for now we
+ * only set obviously unavailable profiles (those that contain only
+ * unavailable ports) to PA_AVAILABLE_NO and all others to
+ * PA_AVAILABLE_UNKNOWN. */
+PA_HASHMAP_FOREACH(profile, u->card->profiles, state) {
+pa_device_port *port;
+void *state2;
+pa_available_t available = PA_AVAILABLE_NO;
+
+/* Don't touch the "off" profile. */
+if (profile->n_sources == 0 && profile->n_sinks == 0)
+continue;
+
+PA_HASHMAP_FOREACH(port, u->card->ports, state2) {
+if (!pa_hashmap_get(port->profiles, profile->name))
+continue;
+
+if (port->available != PA_AVAILABLE_NO) {
+available = PA_AVAILABLE_UNKNOWN;
+break;
+}
+}
+
+pa_card_profile_set_available(profile, available);
+}
+
pa_xfree(tports);
return 0;
}
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 5/6] card: simplify setting pa_card.name
10.06.2016 22:55, Tanu Kaskinen пишет:
---
src/pulsecore/card.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/pulsecore/card.c b/src/pulsecore/card.c
index bc5b75b..896e959 100644
--- a/src/pulsecore/card.c
+++ b/src/pulsecore/card.c
@@ -122,7 +122,6 @@ void pa_card_new_data_done(pa_card_new_data *data) {
pa_card *pa_card_new(pa_core *core, pa_card_new_data *data) {
pa_card *c;
-const char *name;
void *state;
pa_card_profile *profile;
pa_device_port *port;
@@ -135,16 +134,15 @@ pa_card *pa_card_new(pa_core *core, pa_card_new_data
*data) {
c = pa_xnew0(pa_card, 1);
-if (!(name = pa_namereg_register(core, data->name, PA_NAMEREG_CARD, c,
data->namereg_fail))) {
+if (!(c->name = pa_xstrdup(pa_namereg_register(core, data->name,
PA_NAMEREG_CARD, c, data->namereg_fail {
I think that the old code was more obvious.
pa_namereg_register() could return NULL, you checked for that
immediately, and acted upon the error. Now you pass this NULL through
pa_xstrdup(). This causes the reader to think what pa_xstrdup does with
a NULL. Yes, it returns a NULL, but I had to look at the source.
pa_xfree(c);
return NULL;
}
-pa_card_new_data_set_name(data, name);
+pa_card_new_data_set_name(data, c->name);
pa_hook_fire(>hooks[PA_CORE_HOOK_CARD_NEW], data);
c->core = core;
-c->name = pa_xstrdup(data->name);
c->proplist = pa_proplist_copy(data->proplist);
c->driver = pa_xstrdup(pa_path_get_filename(data->driver));
c->module = data->module;
--
Alexander E. Patrakov
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 4/6] card: remove pa_card_new_data.active_profile
10.06.2016 22:55, Tanu Kaskinen пишет:
It's not being used any more.
Looks OK to me.
--
Alexander E. Patrakov
---
src/pulsecore/card.c | 8
src/pulsecore/card.h | 5 -
2 files changed, 13 deletions(-)
diff --git a/src/pulsecore/card.c b/src/pulsecore/card.c
index a0c3d93..bc5b75b 100644
--- a/src/pulsecore/card.c
+++ b/src/pulsecore/card.c
@@ -96,13 +96,6 @@ void pa_card_new_data_set_name(pa_card_new_data *data, const
char *name) {
data->name = pa_xstrdup(name);
}
-void pa_card_new_data_set_profile(pa_card_new_data *data, const char *profile)
{
-pa_assert(data);
-
-pa_xfree(data->active_profile);
-data->active_profile = pa_xstrdup(profile);
-}
-
void pa_card_new_data_set_preferred_port(pa_card_new_data *data,
pa_direction_t direction, pa_device_port *port) {
pa_assert(data);
@@ -125,7 +118,6 @@ void pa_card_new_data_done(pa_card_new_data *data) {
pa_hashmap_free(data->ports);
pa_xfree(data->name);
-pa_xfree(data->active_profile);
}
pa_card *pa_card_new(pa_core *core, pa_card_new_data *data) {
diff --git a/src/pulsecore/card.h b/src/pulsecore/card.h
index fd1fe0a..5699475 100644
--- a/src/pulsecore/card.h
+++ b/src/pulsecore/card.h
@@ -101,15 +101,11 @@ typedef struct pa_card_new_data {
pa_module *module;
pa_hashmap *profiles;
-char *active_profile;
-
pa_hashmap *ports;
pa_device_port *preferred_input_port;
pa_device_port *preferred_output_port;
bool namereg_fail:1;
-
-bool save_profile:1;
} pa_card_new_data;
typedef struct {
@@ -125,7 +121,6 @@ void pa_card_profile_set_available(pa_card_profile *c,
pa_available_t available)
pa_card_new_data *pa_card_new_data_init(pa_card_new_data *data);
void pa_card_new_data_set_name(pa_card_new_data *data, const char *name);
-void pa_card_new_data_set_profile(pa_card_new_data *data, const char *profile);
void pa_card_new_data_set_preferred_port(pa_card_new_data *data,
pa_direction_t direction, pa_device_port *port);
void pa_card_new_data_done(pa_card_new_data *data);
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 3/6] card: move profile selection after pa_card_new()
10.06.2016 22:55, Tanu Kaskinen пишет:
I want module-alsa-card to set the availability of unavailable
profiles before the initial card profile gets selected, so that the
selection logic can use correct availability information.
module-alsa-card initializes the jack state after calling
pa_card_new(), however, and the profile selection happens in
pa_card_new(). This patch solves that by moving parts of pa_card_new()
to pa_card_choose_initial_profile() and pa_card_put().
pa_card_choose_initial_profile() applies the profile selection policy,
so module-alsa-card can first call pa_card_new(), then initialize the
jack state, and then call pa_card_choose_initial_profile(). After that
module-alsa-card can still override the profile selection policy, in
case module-alsa-card was loaded with the "profile" argument. Finally,
pa_card_put() finalizes the card creation.
An alternative solution would have been to move the jack
initialization to happen before pa_card_new() and use pa_card_new_data
instead of pa_card in the jack initialization code, but I disliked
that idea (I want to get rid of the "new data" pattern eventually).
The order in which the initial profile policy is applied is reversed
in this patch. Previously the first one to set it won, now the last
one to set it wins. I think this is better, because if you have N
parties that want to set the profile, we avoid checking N times
whether someone else has already set the profile.
Looks OK to me, but I would like an extra confirmation whether in the
UCM case the sequence of mixer accesses is the same before and after the
patch.
--
Alexander E. Patrakov
---
src/modules/alsa/module-alsa-card.c | 31 ++---
src/modules/bluetooth/module-bluez4-device.c | 31 +
src/modules/bluetooth/module-bluez5-device.c | 2 +
src/modules/macosx/module-coreaudio-device.c | 2 +
src/modules/module-card-restore.c| 36 +++---
src/pulsecore/card.c | 99 +---
src/pulsecore/card.h | 9 +++
src/pulsecore/core.h | 1 +
8 files changed, 143 insertions(+), 68 deletions(-)
diff --git a/src/modules/alsa/module-alsa-card.c
b/src/modules/alsa/module-alsa-card.c
index 1ab2ea2..1976230 100644
--- a/src/modules/alsa/module-alsa-card.c
+++ b/src/modules/alsa/module-alsa-card.c
@@ -671,7 +671,7 @@ int pa__init(pa_module *m) {
struct userdata *u;
pa_reserve_wrapper *reserve = NULL;
const char *description;
-const char *profile = NULL;
+const char *profile_str = NULL;
char *fn = NULL;
bool namereg_fail = false;
@@ -799,15 +799,6 @@ int pa__init(pa_module *m) {
goto fail;
}
-if ((profile = pa_modargs_get_value(u->modargs, "profile", NULL))) {
-if (pa_hashmap_get(data.profiles, profile))
-pa_card_new_data_set_profile(, profile);
-else {
-pa_log("No such profile: %s", profile);
-goto fail;
-}
-}
-
u->card = pa_card_new(m->core, );
pa_card_new_data_done();
@@ -821,6 +812,26 @@ int pa__init(pa_module *m) {
(pa_hook_cb_t) card_suspend_changed, u);
init_jacks(u);
+
+pa_card_choose_initial_profile(u->card);
+
+/* If the "profile" modarg is given, we have to override whatever the usual
+ * policy chose in pa_card_choose_initial_profile(). */
+profile_str = pa_modargs_get_value(u->modargs, "profile", NULL);
+if (profile_str) {
+pa_card_profile *profile;
+
+profile = pa_hashmap_get(u->card->profiles, profile_str);
+if (!profile) {
+pa_log("No such profile: %s", profile_str);
+goto fail;
+}
+
+pa_card_set_profile(u->card, profile, false);
+}
+
+pa_card_put(u->card);
+
init_profile(u);
init_eld_ctls(u);
diff --git a/src/modules/bluetooth/module-bluez4-device.c
b/src/modules/bluetooth/module-bluez4-device.c
index a2de525..13fb7ab 100644
--- a/src/modules/bluetooth/module-bluez4-device.c
+++ b/src/modules/bluetooth/module-bluez4-device.c
@@ -2238,7 +2238,7 @@ static int add_card(struct userdata *u) {
pa_bluez4_profile_t *d;
pa_bluez4_form_factor_t ff;
char *n;
-const char *default_profile;
+const char *profile_str;
const pa_bluez4_device *device;
const pa_bluez4_uuid *uuid;
@@ -2298,16 +2298,6 @@ static int add_card(struct userdata *u) {
*d = PA_BLUEZ4_PROFILE_OFF;
pa_hashmap_put(data.profiles, p->name, p);
-if ((default_profile = pa_modargs_get_value(u->modargs, "profile", NULL)))
{
-if (pa_hashmap_get(data.profiles, default_profile))
-pa_card_new_data_set_profile(, default_profile);
-else {
-pa_log("Profile '%s' not valid or not supported by device.",
default_profile);
-pa_card_new_data_done();
-
Re: [pulseaudio-discuss] [PATCH v2 2/6] card: don't allow the CARD_NEW hook to fail
10.06.2016 22:55, Tanu Kaskinen пишет:
There is currently no use for allowing modules to cancel card creation,
and I don't see need for that in the future either. Let's simplify
things by removing the failure handling code.
---
src/pulsecore/card.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/src/pulsecore/card.c b/src/pulsecore/card.c
index 410746b..0ac70b9 100644
--- a/src/pulsecore/card.c
+++ b/src/pulsecore/card.c
@@ -149,12 +149,7 @@ pa_card *pa_card_new(pa_core *core, pa_card_new_data
*data) {
}
pa_card_new_data_set_name(data, name);
-
-if (pa_hook_fire(>hooks[PA_CORE_HOOK_CARD_NEW], data) < 0) {
-pa_xfree(c);
-pa_namereg_unregister(core, name);
-return NULL;
-}
+pa_hook_fire(>hooks[PA_CORE_HOOK_CARD_NEW], data);
No opinion here. Maybe the new code is OK, or maybe an assert should be
added so that it is explicit that the hook is not expected to fail.
c->core = core;
c->name = pa_xstrdup(data->name);
--
Alexander E. Patrakov
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH v2 1/6] alsa, bluetooth: fail if user-requested profile doesn't exist
10.06.2016 22:55, Tanu Kaskinen wrote:
If we can't fulfill the user request fully, I think we shouldn't
fulfill it at all, to make it clear that the requested operation
didn't succeed.
---
src/modules/alsa/module-alsa-card.c | 10 --
src/modules/bluetooth/module-bluez4-device.c | 7 +--
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/modules/alsa/module-alsa-card.c
b/src/modules/alsa/module-alsa-card.c
index e5cc4ae..1ab2ea2 100644
--- a/src/modules/alsa/module-alsa-card.c
+++ b/src/modules/alsa/module-alsa-card.c
@@ -799,8 +799,14 @@ int pa__init(pa_module *m) {
goto fail;
}
-if ((profile = pa_modargs_get_value(u->modargs, "profile", NULL)))
-pa_card_new_data_set_profile(, profile);
+if ((profile = pa_modargs_get_value(u->modargs, "profile", NULL))) {
+if (pa_hashmap_get(data.profiles, profile))
+pa_card_new_data_set_profile(, profile);
+else {
+pa_log("No such profile: %s", profile);
+goto fail;
Missed call to pa_card_new_data_done(); ?
+}
+}
u->card = pa_card_new(m->core, );
pa_card_new_data_done();
diff --git a/src/modules/bluetooth/module-bluez4-device.c
b/src/modules/bluetooth/module-bluez4-device.c
index 9a921a5..a2de525 100644
--- a/src/modules/bluetooth/module-bluez4-device.c
+++ b/src/modules/bluetooth/module-bluez4-device.c
@@ -2301,8 +2301,11 @@ static int add_card(struct userdata *u) {
if ((default_profile = pa_modargs_get_value(u->modargs, "profile", NULL)))
{
if (pa_hashmap_get(data.profiles, default_profile))
pa_card_new_data_set_profile(, default_profile);
-else
-pa_log_warn("Profile '%s' not valid or not supported by device.",
default_profile);
+else {
+pa_log("Profile '%s' not valid or not supported by device.",
default_profile);
+pa_card_new_data_done();
+return -1;
+ }
}
u->card = pa_card_new(u->core, );
--
Alexander E. Patrakov
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa: reread configuration when opening new devices
22.05.2016 02:03, Alexander E. Patrakov wrote: If a card has been hot-plugged after pulseaudio start, alsa-lib still has old configuration in memory, which doesn't have PCM definitions for the new card. Thus, this error appears, and the device doesn't work: I: [pulseaudio] (alsa-lib)confmisc.c: Unable to find definition 'cards.USB-Audio.pcm.front.0:CARD=0' I: [pulseaudio] (alsa-lib)conf.c: function snd_func_refer returned error: No such file or directory I: [pulseaudio] (alsa-lib)conf.c: Evaluate error: No such file or directory I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM front:0 I: [pulseaudio] alsa-util.c: Error opening PCM device front:0: No such file or directory The snd_config_update_free_global() function makes alsa-lib forget any cached configuration and reparse all PCM definitions from scratch next time it is told to open anything. The trick has been copied from Phonon. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=54029 Signed-off-by: Alexander E. Patrakov <patra...@gmail.com> Obviously, the proposed patch is invalid if PulseAudio calls snd_something_open() from more than one thread. I don't know if this is the case. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] alsa: reread configuration when opening new devices
If a card has been hot-plugged after pulseaudio start, alsa-lib still has
old configuration in memory, which doesn't have PCM definitions for the
new card. Thus, this error appears, and the device doesn't work:
I: [pulseaudio] (alsa-lib)confmisc.c: Unable to find definition
'cards.USB-Audio.pcm.front.0:CARD=0'
I: [pulseaudio] (alsa-lib)conf.c: function snd_func_refer returned error: No
such file or directory
I: [pulseaudio] (alsa-lib)conf.c: Evaluate error: No such file or directory
I: [pulseaudio] (alsa-lib)pcm.c: Unknown PCM front:0
I: [pulseaudio] alsa-util.c: Error opening PCM device front:0: No such file or
directory
The snd_config_update_free_global() function makes alsa-lib forget any
cached configuration and reparse all PCM definitions from scratch next
time it is told to open anything.
The trick has been copied from Phonon.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=54029
Signed-off-by: Alexander E. Patrakov <patra...@gmail.com>
---
src/modules/alsa/alsa-sink.c| 9 +
src/modules/alsa/alsa-source.c | 9 +
src/modules/alsa/module-alsa-card.c | 8
3 files changed, 26 insertions(+)
diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
index 2fdebe0..63674e2 100644
--- a/src/modules/alsa/alsa-sink.c
+++ b/src/modules/alsa/alsa-sink.c
@@ -2146,6 +2146,15 @@ pa_sink *pa_alsa_sink_new(pa_module *m, pa_modargs *ma,
const char*driver, pa_ca
b = use_mmap;
d = use_tsched;
+/* Force ALSA to reread its configuration if module-alsa-card didn't
+ * do it for us. This matters if our device was hot-plugged after ALSA
+ * has already read its configuration - see
+ * https://bugs.freedesktop.org/show_bug.cgi?id=54029
+ */
+
+if (!card)
+snd_config_update_free_global();
+
if (mapping) {
if (!(dev_id = pa_modargs_get_value(ma, "device_id", NULL))) {
diff --git a/src/modules/alsa/alsa-source.c b/src/modules/alsa/alsa-source.c
index 4683dfe..0820b48 100644
--- a/src/modules/alsa/alsa-source.c
+++ b/src/modules/alsa/alsa-source.c
@@ -1854,6 +1854,15 @@ pa_source *pa_alsa_source_new(pa_module *m, pa_modargs
*ma, const char*driver, p
b = use_mmap;
d = use_tsched;
+/* Force ALSA to reread its configuration if module-alsa-card didn't
+ * do it for us. This matters if our device was hot-plugged after ALSA
+ * has already read its configuration - see
+ * https://bugs.freedesktop.org/show_bug.cgi?id=54029
+ */
+
+if (!card)
+snd_config_update_free_global();
+
if (mapping) {
if (!(dev_id = pa_modargs_get_value(ma, "device_id", NULL))) {
diff --git a/src/modules/alsa/module-alsa-card.c
b/src/modules/alsa/module-alsa-card.c
index e5cc4ae..adb942b 100644
--- a/src/modules/alsa/module-alsa-card.c
+++ b/src/modules/alsa/module-alsa-card.c
@@ -715,6 +715,14 @@ int pa__init(pa_module *m) {
}
pa_modargs_get_value_boolean(u->modargs, "use_ucm", >use_ucm);
+
+/* Force ALSA to reread its configuration. This matters if our device
+ * was hot-plugged after ALSA has already read its configuration - see
+ * https://bugs.freedesktop.org/show_bug.cgi?id=54029
+ */
+
+snd_config_update_free_global();
+
if (u->use_ucm && !pa_alsa_ucm_query_profiles(>ucm,
u->alsa_card_index)) {
pa_log_info("Found UCM profiles");
--
2.8.2
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Results of valgrinding today's git version of pulseaudio
When starting pulseaudio under valgrind, I get this: ==10853== Conditional jump or move depends on uninitialised value(s) ==10853==at 0x5C91288: shm_attach (shm.c:380) ==10853==by 0x5C91B68: pa_shm_cleanup (shm.c:453) ==10853==by 0x5C91D4C: sharedmem_create (shm.c:150) ==10853==by 0x5C91D4C: pa_shm_create_rw (shm.c:239) ==10853==by 0x5C82193: pa_mempool_new (memblock.c:848) ==10853==by 0xF23FFF7: setup_srbchannel (protocol-native.c:2634) ==10853==by 0xF23FFF7: command_auth (protocol-native.c:2864) ==10853==by 0x5C8989E: pa_pdispatch_run (pdispatch.c:346) ==10853==by 0xF2426C4: pstream_packet_callback (protocol-native.c:4989) ==10853==by 0x5C8C216: do_read (pstream.c:987) ==10853==by 0x5C8EEF3: do_pstream_read_write (pstream.c:227) ==10853==by 0x510040B: dispatch_pollfds (mainloop.c:655) ==10853==by 0x510040B: pa_mainloop_dispatch (mainloop.c:898) ==10853==by 0x510080B: pa_mainloop_iterate (mainloop.c:929) ==10853==by 0x51008AF: pa_mainloop_run (mainloop.c:944) ==10853== ==10853== Conditional jump or move depends on uninitialised value(s) ==10853==at 0x5C8C91D: pa_cmsg_ancil_data_close_fds (pstream.c:193) ==10853==by 0x5C8DE57: do_write (pstream.c:759) ==10853==by 0x5C8EEB7: do_pstream_read_write (pstream.c:233) ==10853==by 0x510040B: dispatch_pollfds (mainloop.c:655) ==10853==by 0x510040B: pa_mainloop_dispatch (mainloop.c:898) ==10853==by 0x510080B: pa_mainloop_iterate (mainloop.c:929) ==10853==by 0x51008AF: pa_mainloop_run (mainloop.c:944) ==10853==by 0x406E3B: main (main.c:1141) ==10853== ==10853== Conditional jump or move depends on uninitialised value(s) ==10853==at 0x5C8C91D: pa_cmsg_ancil_data_close_fds (pstream.c:193) ==10853==by 0x5C8CA90: item_free (pstream.c:371) ==10853==by 0x5C8DDC2: do_write (pstream.c:775) ==10853==by 0x5C8EEB7: do_pstream_read_write (pstream.c:233) ==10853==by 0x510040B: dispatch_pollfds (mainloop.c:655) ==10853==by 0x510040B: pa_mainloop_dispatch (mainloop.c:898) ==10853==by 0x510080B: pa_mainloop_iterate (mainloop.c:929) ==10853==by 0x51008AF: pa_mainloop_run (mainloop.c:944) ==10853==by 0x406E3B: main (main.c:1141) ==10853== Can anyone familiar with this code look whether this is a bug or a false positive? Memory leaks (when I get a good summary of them) will be reported separately. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] [PATCH] Disabled LFE remixing by default
The current LFE crossover filter removes low frequencies from the main
channels and puts them into the LFE channel with the wrong amplitude.
It is not known for sure what is the correct relative amplitude (acoustic
measurements are required with real hardware), and changing that might
introduce a new bug, "it clips the LFE channel".
So just disable the feature by default until a better understanding
emerges how it should work. This, essentially, returns the defaults
to their state as of PulseAudio 6.0.
Some more observations:
- Most of available active analog speakers on the market do the
necessary crossover filtering already, and HDMI receivers can be
configured to do that, too, so a crossover filter in PulseAudio is
harmful in these use cases.
- The "laptop with a builtin subwoofer" use case requires manual
configuration anyway because the default crossover frequency (120 Hz) is
wrong for laptop speakers.
- Finally, Windows 10 with a built-in USB audio driver does not synthesize
the LFE channel given a 5.1 card and a stereo audio stream by default.
Hides: https://bugs.freedesktop.org/show_bug.cgi?id=95021
Signed-off-by: Alexander E. Patrakov <patra...@gmail.com>
---
man/pulse-daemon.conf.5.xml.in | 4 ++--
src/daemon/daemon-conf.c | 4 ++--
src/daemon/daemon.conf.in | 4 ++--
src/pulsecore/core.c | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/man/pulse-daemon.conf.5.xml.in b/man/pulse-daemon.conf.5.xml.in
index 1abc94f..ed77158 100644
--- a/man/pulse-daemon.conf.5.xml.in
+++ b/man/pulse-daemon.conf.5.xml.in
@@ -136,12 +136,12 @@ License along with PulseAudio; if not, see
<http://www.gnu.org/licenses/>.
channel is available as well. If no input LFE channel is
available the output LFE channel will always be 0. If no output
LFE channel is available the signal on the input LFE channel
- will be ignored. Defaults to yes.
+ will be ignored. Defaults to no.
lfe-crossover-freq= The crossover frequency (in Hz) for the
- LFE filter. Defaults to 120 Hz. Set it to 0 to disable the LFE
filter.
+ LFE filter. Set it to 0 to disable the LFE filter. Defaults to 0.
diff --git a/src/daemon/daemon-conf.c b/src/daemon/daemon-conf.c
index 965a5c8..4277301 100644
--- a/src/daemon/daemon-conf.c
+++ b/src/daemon/daemon-conf.c
@@ -82,8 +82,8 @@ static const pa_daemon_conf default_conf = {
.log_time = false,
.resample_method = PA_RESAMPLER_AUTO,
.disable_remixing = false,
-.disable_lfe_remixing = false,
-.lfe_crossover_freq = 120,
+.disable_lfe_remixing = true,
+.lfe_crossover_freq = 0,
.config_file = NULL,
.use_pid_file = true,
.system_instance = false,
diff --git a/src/daemon/daemon.conf.in b/src/daemon/daemon.conf.in
index b48afa2..fcc9cb9 100644
--- a/src/daemon/daemon.conf.in
+++ b/src/daemon/daemon.conf.in
@@ -54,8 +54,8 @@ ifelse(@HAVE_DBUS@, 1, [dnl
; resample-method = speex-float-1
; enable-remixing = yes
-; enable-lfe-remixing = yes
-; lfe-crossover-freq = 120
+; enable-lfe-remixing = no
+; lfe-crossover-freq = 0
; flat-volumes = yes
diff --git a/src/pulsecore/core.c b/src/pulsecore/core.c
index 6d102f5..2a96dfa 100644
--- a/src/pulsecore/core.c
+++ b/src/pulsecore/core.c
@@ -142,8 +142,8 @@ pa_core* pa_core_new(pa_mainloop_api *m, bool shared, bool
enable_memfd, size_t
c->realtime_scheduling = false;
c->realtime_priority = 5;
c->disable_remixing = false;
-c->disable_lfe_remixing = false;
-c->lfe_crossover_freq = 120;
+c->disable_lfe_remixing = true;
+c->lfe_crossover_freq = 0;
c->deferred_volume = true;
c->resample_method = PA_RESAMPLER_SPEEX_FLOAT_BASE + 1;
--
2.8.2
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [ANNOUNCE] PulseAudio 9.0 RC1
14.05.2016 23:17, Felipe Sateler пишет: On 12 May 2016 at 08:15, Arun Raghavan <a...@arunraghavan.net> wrote: Hi folks, I'm pleased to announce that the first release candidate for PulseAudio 9.0 is out. I have just uploaded an update to debian experimental. Please test! One problem that I am hitting (with an earlier commit, fcee3da - did not test the actual RC1 yet) is that monitor sources don't seem to work reliably. E.g. pavucontrol's meter shows zero even though mpv is playing. This misbehaviour applies only to monitor sources and playback streams, disappears when I move the stream to another sink, and sometimes reappears when I move it back. I will bisect later, as I know that in 8.0 and 93822f9 there was no such bug. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] bluetooth source not created
09.05.2016 18:42, Marco Trapanese пишет: Il 09/05/2016 15:38, Marco Trapanese ha scritto: Removing that flag I now see the bluez source with pactl list sources. But when I start playing a song from the smartphone something weird happens: I add that pactl modules shows: Module #14 Name: module-bluez5-device Argument: path=/org/bluez/hci0/dev_xx_xx_xx_xx_xx_xx Usage counter: 1 Properties: module.author = "João Paulo Rechi Vita" module.description = "BlueZ 5 Bluetooth audio sink and source" module.version = "8.0" Module #15 Name: module-loopback Argument: source="bluez_source.xx_xx_xx_xx_xx_xx" source_dont_move="true" sink_input_properties="media.role=music" Usage counter: n/a Properties: module.author = "Pierre-Louis Bossart" module.description = "Loopback from source to sink" module.version = "8.0" And it "play" if I pair the smartphone as user! The audio is pretty bad, though... lot of stutters and interruptions. I suggest that you run pulseaudio as the same user that other software runs as (i.e. not in system mode). This will allow using shm safely. The other tunable is the resampler. Nowadays the default is either speex-float-1 or speex-fixed-1, depending on how the speex library was compiled. Both of those resamplers are objectively much worse than the default in Windows 7 (i.e. they create easily audible distortions of high-frequency pure tones), but should still be good enough (as in: nobody would notice by ear the difference from the perfect resampler on 99.99% of released music albums). However, this is still too much work for embedded CPUs. You can try setting the resampler to speex-float-0 in daemon.conf. It will fall back to speex-fixed-0 if your speex library has been compiled with fixed point. Also, verify whether your speex library is compiled with fixed point. On embedded devices, fixed-point is faster, but some speex API (related to automatic gain control and similar things) becomes unavailable, so it may or may not be an option for your application. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] bluetooth source not created
09.05.2016 17:21, Marco Trapanese wrote: I'm running pulseaudio8 and bluez5 in a buildroot environment (RPi3). When I connect the smartphone I can successfully pair and authorize UUIDs for Advanced Audio Distribution and for A/V Remote Control. It doesn't ask for Audio Source. In fact pactl list sources doesn't show the bluetooth source, thus I cannot loopback with the local sink. The daemon is started in this way: pulseaudio --system --daemonize --disallow-exit --disallow-module-loading --exit-idle-time=-1 --disable-shm --fail The problem is likely --disallow-module-loading, because module-loopback is, well, a module. You can remove this argument if you have no users except root on your system. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Should we ban Raymond from bugzilla? (No)
04.05.2016 11:00, Arun Raghavan wrote: On 4 May 2016 at 11:23, David Henningsson <di...@ubuntu.com> wrote: On 2016-05-04 06:49, Alexander E. Patrakov wrote: Raymond produces too many irrelevant comments and seems not to understand what he is talking about or what was already debugged. May I request a ban in order to increase our signal-to-noise ratio? First; I think it's inappropriate to ask this 1) in a public forum and 2) without involving Raymond in the conversation. Strongly agree. But since you asked in public, I'm inclined to answer in public. I've seen a lot of Raymond's comments over the years both here and in the Ubuntu bug tracker, sometimes he's spot on and very helpful, and sometimes he's discussing things that are irrelevant to the bug, which can be confusing. Maybe we have a tendency to notice the latter but not the former? Again, very true. Raymond has been extremely helpful on several occasions and he's clearly well-versed with a lot of things HDA-related and otherwise. I apologize for the email that started this thread. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Should we ban Raymond from bugzilla?
Raymond produces too many irrelevant comments and seems not to understand what he is talking about or what was already debugged. May I request a ban in order to increase our signal-to-noise ratio? -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to disable microphone auto adjust?
19.04.2016 19:22, Luis Cavalheiro пишет: Additional data: I use webrtc echo cancellation module. It may be relevant. Yes, it is relevant. Please pass this argument to module-echo-cancel: aec_args="analog_gain_control=0\ digital_gain_control=0" -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to disable microphone auto adjust?
19.04.2016 19:17, Luis Cavalheiro пишет: Guys, I want to disable microphone auto adjust. I found this feature very annoying (my voice is very irregular, which means mic input volume jumps from 50% to 100% in less than 10s and then back to 50% in same amount of time), and I need to turn it off. Sadly to me, even with Google help I couldn't find any documentation about how to disable microphone auto adjust. Things I've tried: - turn off flat volumes and deferrence on daemon.conf; - turn off all mic boost volumes on default.pa <http://default.pa>. I would love any advice about how to disable PulseAudio microphone auto adjustment. Honestly, mic auto adjust is bullshit and I'm tired of it. Hello. PulseAudio, by itself, auto-adjusts microphone input only if module-echo-cancel is loaded. However, it is not the loaded by default, so it's more likely that some application (Skype or Chromium, most probably) adjusts the gain for you. For further troubleshooting, please provide the output of these two commands (run them as your user, not as root) when you find that the microphone gain has been adjusted against your will: LC_ALL=C pactl list sources LC_ALL=C pactl list source-outputs -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Splitting a 7.1 device into virtual 5.1 + 2.0 devices?
19.04.2016 18:39, Tanu Kaskinen wrote: On Tue, 2016-04-12 at 22:32 +0200, 紅 蒼穹 wrote: On Sat, 2016-04-09 at 16:22 +0200, 紅 蒼穹 wrote: When I have lfe remixing = yes (default): - LFE is mixed to stereo output when downmixing from 5.1 - there are no low frequencies present at all in 5.1 output when playing a stereo track. LFE remixing is supposed to move low frequencies from all other channels to the LFE channel by default. Are you saying that the LFE channel doesn't get low frequencies either? At least I can't hear any on any non-5.1 content. It is correctly present with 5.1 content though That sounds bad. I opened a bug report: https://bugs.freedesktop.org/show_bug.cgi?id=95021 Speaking of volumes, is there an option to somehow boost only the LFE in pulseaudio? Changing it with alsamixer gets overridden next time I use my media keys. You can use e.g. pavucontrol to control the individual channels (with pavucontrol you need to first turn off the "lock channels together" option, represented by the shield icon). The media keys might still lose the per-channel differences, though. I believe this is the same "do we need sum or average" concern as I expressed in https://lists.freedesktop.org/archives/pulseaudio-discuss/2015-February/023224.html -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Freeze impending
2016-04-15 18:01 GMT+05:00 Arun Raghavan <a...@accosted.net>: > Hi folks, > Tanu rightly pointed out that we're almost upon the freeze date for > 9.0, which is 22nd Apr. > > I know we've got a large patch backlog, so if your patches didn't make > it, please be patient and we'll get to them. > > If you think something is crucial for this release (critical bug fix, > regression, etc.), please holler now. We still don't have https://freedesktop.org/software/pulseaudio/webrtc-audio-processing/webrtc-audio-processing-0.2.tar.xz -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] mainwindow: Don't add a border on the outermost vbox
31.03.2016 16:44, a...@accosted.net пишет: From: Arun Raghavan <g...@arunraghavan.net> It adds a thick border around along the edges that looks quite ugly. The patch does what it says, but the GtkNotebook tabs "glued" to the top of the window also don't look nice in MATE from my viewpoint. Caja's settings dialog (and some other MATE settings dialogs that use tabbed notebooks, as well as pitivi's Project Settings dialog) has this thick border. OTOH, MATE terminal does the ugly "tabs glued to the titlebar" thingy if one hides the menu, the same is also seen in linphone preferences. So - no real (consistency-based) opinion here. If you can find anything in the HIG that explains that the border should not exist in this case, please add a link in the commit message, and/or quote directly, and push it. -- Alexander E. Patrakov --- src/pavucontrol.glade | 1 - 1 file changed, 1 deletion(-) diff --git a/src/pavucontrol.glade b/src/pavucontrol.glade index 219f5a2..66b5852 100644 --- a/src/pavucontrol.glade +++ b/src/pavucontrol.glade @@ -698,7 +698,6 @@ True False -12 12 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Rethinking how we do reviews
28.03.2016 12:13, Arun Raghavan wrote: Our current way of doing things is good for keeping up code quality, but I think over time, with such a large patch backlog, we end up spending more and more time performing reviews, and less and less time working on features. This becomes quite draining and drops our overall productivity in contributing to the project. I think it is in our interests to think how to get these features, where possible, without reviewing too many patches and without sacrificing the code quality of PulseAudio. That includes encouraging our contributors to implement features externally to PulseAudio if it is easier. And an external module SDK would also be a step forward. I also think I should try porting the existing RAOP2 patch set to make it an ALSA plugin instead, to set an example of the "externally where it is easier" rule. -- Alexander E. Patrakov ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
