Re: [pulseaudio-discuss] How to disable switch on HDMI audio output ?
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. There's a guide here on how to do that for an USB audio device here via setting "PULSE_IGNORE" in /etc/udev/rules.d. https://jamielinux.com/blog/tell-pulseaudio-to-ignore-a-usb-device-using-udev/ It should work for HDMI audio as well if you adapt the device matching rule for your specific hardware. You can get the required info on your device by looking for sysfs.path in "pactl list" and then using "udevadm info" to inspect that path. Best regards Tomaž ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Error using with Echo Cancellation Module with VoIP
Hi Paul, On 11. 06. 2018 16:43, Dferop Aero wrote: I have always the same error when i use the Echo Cancellation Module. I'm seeing these kinds of errors constantly with module-echo-cancel (also running on ARM): module-echo-cancel.c: Doing resync module-echo-cancel.c: Playback too far ahead (22312), drop source 2 852 module-echo-cancel.c: Doing resync module-echo-cancel.c: Playback after capture (-1309936), drop sink 167708 I don't know what their cause is, but for me they don't seem to be causing any noticeable audio quality problems. I do find the current state of echo cancellation in Pulseaudio unusable, but that seems to be due to the echo cancellation algorithm not working properly for my use case. It might be the same for you. I've made an updated libwebrtc-audio-processing and a patched module-echo-cancel that works significantly better for me. I've sent it out to this list three months ago without much response. You might want to try it if it helps with your problems. You can get the code here (both should build with "dpkg-buildpackage" on debian-like systems): https://github.com/avian2/webrtc-audio-processing/tree/debian https://github.com/avian2/pulseaudio/tree/debian Best regards Tomaž ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Detecting success/error in cli protocol?
On 23. 05. 2018 16:42, Tanu Kaskinen wrote: On Thu, 2018-05-17 at 08:28 +0200, Tomaž Šolc wrote: Does anyone have any thoughts on how proper error handling could be implemented in the cli interface? I would be happy to work on a patch to fix this. Getting an error message from the "play-file" command is just a matter of printing the error in pa_cli_command_play_file(). It already prints errors when it detects bad parameters, but if pa_play_file() fails, that doesn't currently result in any error message. A patch for this would be welcome. Ok. I'll prepare a patch for that. You asked about "proper" error handling, and in my view that includes something better than just ad-hoc error messages. The CLI interface is what it is, and I don't like the idea of trying to make it a proper programming interface. The native protocol is what applications should use. Most CLI protocols I've seen have some way of having error handling. Unix/dos shell exit statuses for example, or usbtmc/GPIB protocol for instrumentation. A backwards-compatible approach could be to add a command that prints out the success/error status of the previous command. A "play file" command could be added to the native protocol, although I'm not sure it should. PulseAudio isn't a media player, after all... I understand that playing files isn't something PulseAudio should focus on. The "play-file" does come very handy in the specific embedded application I'm working on. In regard to media playback I need only to play a single .wav, and using "play-file" means that I can offload everything audio-related to the PulseAudio daemon. Best regards Tomaž ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Detecting success/error in cli protocol?
(apologies for sending an incomplete mail earlier) Hi is there a way to detect that a CLI command has succeeded or failed when using the socket interface offered by module-cli-protocol-unix? Specifically I'm currently interested in the "play-file" command (which seems to be only accessible over the CLI interface). If the command fails because the daemon can't read the file, there is no error message returned back through the socket. Any error is only written to syslog. In general I don't see any way of getting back the success/error status of a command. pulse-cli-syntax man page does not mention anything in this regard. "pacmd" also does not signal failures through its exit code. I see that individual handlers in cli-command.c (including pa_cli_command_play_file) return -1 on error, but this status seems to be lost somewhere down the line. Is see that in line_callback() in cli.c the return value of pa_cli_command_execute_line() is ignored. Does anyone have any thoughts on how proper error handling could be implemented in the cli interface? I would be happy to work on a patch to fix this. Best regards Tomaž ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Detecting success/errors in cli protocol?
Hi is there a way to detect that a CLI command has succeeded or failed when using ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Updating the WebRTC AudioProcessing library
On 10. 04. 2018 14:26, Tanu Kaskinen wrote: On Mon, 2018-04-09 at 11:56 +0200, Tomaž Šolc wrote: In general I think there's a question of how heavy a wrapper the "module-echo-cancellation" is supposed to be around the webrtc code. The upstream is very actively reworking large parts of the code. Most likely closely following the changes and ensuring backwards compatibility in PulseAudio, even at the level of module arguments, isn't feasible in the long term. When there's a pressing need to break compatibility, then that can be done, but not otherwise. I see. I restored back the "trace" argument. The lack of documentation is a valid point. Generally I'm of the opinion is that if some API isn't documented, it shouldn't be used. In module-echo-cancel's case that would mean most of the webrtc options shouldn't be used, which of course isn't a good... Unfortunately the whole webrtc part of module-echo-cancel is an exercise in using an internal, undocumented API that is subject to change at any time. See e.g. discussion here. It's from 2012 but AFAIK this situation has not changed: https://groups.google.com/forum/#!topic/discuss-webrtc/pyxD1_BeJvs Still, we find it useful, since it seems to be the best open source echo canceller available at the moment. I removed this default because the new webrtc configuration class seems to define some sensible defaults itself. Individual components no longer need to be explicitly enabled/disabled like before. I think upstream has a much better knowledge of which defaults make sense. For example, high pass filter is disabled by default in the current upstream (while DEFAULT_HIGH_PASS_FILTER was set to true). Shouldn't we then remove all the other defaults as well? The upstream code is in the middle of migration between two configuration systems: Some settings use the new webrtc::AudioProcessing::Config class. That class includes some defaults that have been defined upstream. I made module-echo-cancel respect those defaults (high_pass_filter, residual_echo_detector). Other settings still use the old webrtc::Config class. That class has no defaults. Hence I left in place the old DEFAULT_... macros. Best regards Tomaž ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Updating the WebRTC AudioProcessing library
Dear Tanu, thanks for your comments. My answers to individual questions are in-line below. In general I think there's a question of how heavy a wrapper the "module-echo-cancellation" is supposed to be around the webrtc code. The upstream is very actively reworking large parts of the code. Most likely closely following the changes and ensuring backwards compatibility in PulseAudio, even at the level of module arguments, isn't feasible in the long term. On 01. 04. 2018 12:42, Tanu Kaskinen wrote: You removed the "trace" module argument, which can break previously- working configuration files. Since you added the logging support back in a different way, the "trace" module argument doesn't really need to be removed, since it could still control whether the logging should be enabled or not. The whole "trace" functionality has been removed upstream. I think retaining that parameter isn't useful and using it for something else is confusing. As far as I can see, its existence wasn't even documented anywhere. The previous logging code had separation for different log levels, now only pa_log() is used (which is an alias for pa_log_error()). Does webrtc not provide any more log level separation? The logging is setup with this call: rtc::LogMessage::AddLogToStream(logsink, rtc::LS_INFO); Is LS_INFO the webrtc log level? If so, then it looks like all other log levels than "info" are discarded. Unfortunately, the only way webrtc provides for plugging into its logging system is via the generic LogSink class, which doesn't receive the numeric log level. You can only set the minimum level for the messages that it receives. So at best, all webrtc log levels must be squashed into a single pa_log level (I've changed that to pa_log_info() now) I've now added a "log_level" argument that allows you to set the minimum webrtc level that is logged by PA: https://github.com/avian2/pulseaudio/commit/d97eb2122e9e5f1b251e97661b1b241b959c7b7c Anyway, upstream webrtc logging doesn't seem very useful at the moment. Even at highest verbosity only a few messages are generated on module load (which is why I originally didn't bother too much with it). I: webrtc: (audio_processing_impl.cc:441): Capture post processor activated: 0 I: Render pre processor activated: 0 I: webrtc: (audio_processing_impl.cc:704): Highpass filter activated: 0 I: webrtc: (audio_processing_impl.cc:717): Gain Controller 2 activated: 0 You removed DEFAULT_HIGH_PASS_FILTER, which I think is not a good change. It's good to be able to control the defaults in pulseaudio. I removed this default because the new webrtc configuration class seems to define some sensible defaults itself. Individual components no longer need to be explicitly enabled/disabled like before. I think upstream has a much better knowledge of which defaults make sense. For example, high pass filter is disabled by default in the current upstream (while DEFAULT_HIGH_PASS_FILTER was set to true). The version in AC_INIT in configure.ac needs to be incremented (to 0.4, I presume). Regarding Debian dependency handling: The original binary package name was libwebrtc-audio-processing0 (note the 0 at the end). Version 0.3 broke API and ABI compatibility, which is why the package name was changed to libwebrtc-audio-processing1, so in fact Debian does depend on a particular version. Since it looks like compatibility will be broken again, the Debian package name will change to libwebrtc-audio- processing2. That makes sense. Thanks for the suggestion. Best regards Tomaž ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Starting pulseaudio on embedded as root
Hi On 01. 04. 2018 13:22, Sherif Omran wrote: i created a thin linux image using yocto and i have pulseaudio in the system being installed. But when i start it manually, i get pulse is not intented to start as root. I tried to enable the spawn but even it has not been solved. I have systemv, does it cause a problem? Search for "pulseaudio system mode". This page is a good start: https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/ I got PulseAudio running on an embedded system using system mode generally following the instructions on that page. It works, but it will complain a lot in the logs about running as root. You also need to disable all the different ways PA gets automatically spawned in user mode (at least under systemd that is quite a pain: you have the autospawn feature - /etc/pulse/client.conf and /etc/pulse/client.conf.d/00-disable-autospawn.conf, the systemd per-user units and possibly some other ways I haven't figured out - I still get a spurious non-system mode PA daemon spawned sometimes). You also (usually) need to have PULSE_RUNTIME_PATH=/var/run/pulse environment set for clients. Best regards Tomaž ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] State of the WebRTC AudioProcessing library?
Hi Arun, On 12. 03. 2018 17:49, Arun Raghavan wrote: I'm definitely up for updates to the library. The UPDATING.md file has some rudimentary instructions on what you need. I've got an intermediate update sitting on my laptop, you can find it at: https://github.com/ford-prefect/webrtc-audio-processing Thanks for that. I'll have a look and report back if I manage to make anything useful. Best regards Tomaž ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
