diyAudio

diyAudio (https://www.diyaudio.com/forums/index.php)
-   PC Based (https://www.diyaudio.com/forums/pc-based/)
-   -   Pulseaudio Crossover Rack - multi-way crossover design & implementation with linux (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux.html)

AllenB 26th August 2019 12:45 PM

Using pavucontrol, should my Playback application be -on PaXoverRack.Input, the default input device - Monitor of PaXoverRack.Output, and the default Output device - LineOut.

Also, I think LineOut used to be 'on' something but that has dropped off. Everything was working fine until earlier today and I'm beginning to repeat things.

DarpMalone 26th August 2019 07:47 PM

I've noticed every once in a blue my output channels seem to lose sync (Ex. there'll be a noticeable delay on two or four channels in relation to the others). This happens on the Pi 4 with 8Ch HDMI extractor with the latest version of Raspbian but very rarely... I haven't figured out what the conditions might be when this begins to happen although I don't believe it happens while under heavy CPU load.

I wasn't so much worried about it happening on the Pi 4 because it hasn't happened in days and when it does occur it's so slight (maybe 2-4ms) that one might not even notice. I figured I'd eventually figure it out or that it might sort itself out with an upcoming update of of Raspbian with better driver support for the Pi 4.

Last weekend however, I fired up the Atomic Pi SBPC running a fresh install of Lubuntu v19.04 (Same HDMI extractor)... This has the same issue but it happens much more often and to a much greater degree. Even restarting pulseAudio or fully rebooting. I've noticed that it's actually not a static time delay on certain channels, the CH offset ranges from approx 250ms and slowly catches up to the other channels and eventually drifts back and forth. It's crazy... Also when it's happening it's accompanied by ridiculous audio glitches and dropouts. It's the type of noise you'd hear if the CPU was at 100% but the 1st of 4-cores only reads around 18% and the other 3 cores are usually less than that, plus the OS is otherwise very responsive.

Any idea why this might be happening?

AllenB 27th August 2019 08:09 AM

Thank you, I have my EQ back. Apps and input OK. Output through LineOut, with PaXoverRack.output at max. You gotta love computers :rolleyes:

[Feature Request]- The overlay is good, two may be better, and output *.frd :)
Edit: - A couple of reasons why (I currently have paper cutouts on the screen). frd out for editing on a simulator, then back in, also house curve etc. Then to consolidate and reduce the number of EQ plugins.

Tfive 27th August 2019 05:24 PM

Quote:

Originally Posted by DarpMalone (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5896802.html#post5896802)
I've noticed every once in a blue my output channels seem to lose sync (Ex. there'll be a noticeable delay on two or four channels in relation to the others). This happens on the Pi 4 with 8Ch HDMI extractor with the latest version of Raspbian but very rarely... I haven't figured out what the conditions might be when this begins to happen although I don't believe it happens while under heavy CPU load.

I wasn't so much worried about it happening on the Pi 4 because it hasn't happened in days and when it does occur it's so slight (maybe 2-4ms) that one might not even notice. I figured I'd eventually figure it out or that it might sort itself out with an upcoming update of of Raspbian with better driver support for the Pi 4.

Last weekend however, I fired up the Atomic Pi SBPC running a fresh install of Lubuntu v19.04 (Same HDMI extractor)... This has the same issue but it happens much more often and to a much greater degree. Even restarting pulseAudio or fully rebooting. I've noticed that it's actually not a static time delay on certain channels, the CH offset ranges from approx 250ms and slowly catches up to the other channels and eventually drifts back and forth. It's crazy... Also when it's happening it's accompanied by ridiculous audio glitches and dropouts. It's the type of noise you'd hear if the CPU was at 100% but the 1st of 4-cores only reads around 18% and the other 3 cores are usually less than that, plus the OS is otherwise very responsive.

Any idea why this might be happening?

I might have a suspicion, but still wasn't able to 100% confirm it. Please try adding tsched=0 to the module-udev-detect line in your $HOME/.config/pulse/default.pa like this:
Code:

load-module module-udev-detect tsched=0
Then restart pulseaudio. Or better even your OS. Please report back. If we have this confirmed then it's finally time to pursue this bug in pulseaudio.

Tfive 27th August 2019 05:26 PM

Quote:

Originally Posted by AllenB (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5897287.html#post5897287)
Thank you, I have my EQ back. Apps and input OK. Output through LineOut, with PaXoverRack.output at max. You gotta love computers :rolleyes:

[Feature Request]- The overlay is good, two may be better, and output *.frd :)
Edit: - A couple of reasons why (I currently have paper cutouts on the screen). frd out for editing on a simulator, then back in, also house curve etc. Then to consolidate and reduce the number of EQ plugins.

Please elaborate, atm I'm not really getting what your request is about... ;)

DarpMalone 27th August 2019 06:30 PM

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5897719.html#post5897719)
I might have a suspicion, but still wasn't able to 100% confirm it. Please try adding tsched=0 to the module-udev-detect line in your $HOME/.config/pulse/default.pa like this:
Code:

load-module module-udev-detect tsched=0
Then restart pulseaudio. Or better even your OS. Please report back. If we have this confirmed then it's finally time to pursue this bug in pulseaudio.

Just read up on this. Sounds about right... I'll try this out this evening and report back.

Thanks Tfive

DarpMalone 28th August 2019 12:15 AM

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5897719.html#post5897719)
I might have a suspicion, but still wasn't able to 100% confirm it. Please try adding tsched=0 to the module-udev-detect line in your $HOME/.config/pulse/default.pa like this:
Code:

load-module module-udev-detect tsched=0
Then restart pulseaudio. Or better even your OS. Please report back. If we have this confirmed then it's finally time to pursue this bug in pulseaudio.

Well, I've been playing music in JRiver from local files, streaming from the NAS, Streaming via DLNA as well as streaming bluetooth from my phone to Lubuntu for the past hour without a glitch. It looks like adding the tsched=0 did the trick!

I love your PaXoverRack software!
Thanks again Tfive

phofman 28th August 2019 04:28 AM

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5897719.html#post5897719)
Please try adding tsched=0
If we have this confirmed then it's finally time to pursue this bug in pulseaudio.

Good catch, Jürgen. I would not think the timer-based scheduling could timeshift individual channels of one stream, I would assume all channels would be delayed at once. Yet IRQ-based scheduling fixed the problem. Do you have any tip for a bug in PA in this regard? That's very interesting.

AllenB 28th August 2019 04:45 AM

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5897721.html#post5897721)
Please elaborate, atm I'm not really getting what your request is about... ;)

Ok.

Example of using 2 frd overlays. I have a measured response exported from my crossover designing app. I want to tweak that result, and aim for a non-flat target. So I need to see the starting response and the target response (the starting response will combine with the filters, but the target response just sits there as a fixed overlay).

2 examples of saving frds. To take back to my crossover designing app. And when I have too many EQ plugins and want to simplify the setup but need to save the result to use as a target on the new set.

phofman 28th August 2019 08:57 AM

Jürgen, please do you have any experience with capturing from one soundcard (module-alsa-source) and playing the incoming data (after your processing) to another soundcard (module-alsa-sink) with independent clock? The module-combine-sink adaptively resamples only between several sinks, I could not find any solution for adaptively resampling between source - sink.

I am asking because Charlie Laub with me have made the usb-audio gadget linux driver work in windows, which turns RPi4 (with USB OTG port) into a regular USB sound device (playback only for now, any samplerate, any number of channels). This allows building an "intelligent" USB soundcard with any processing running in linux on RPi. Data from the USB gadget are available on RPi as a virtual alsa capture soundcard (listed in arecord -l).

But the capture soundcard (source) is timed by the USB controller of the host (adaptive mode), whereas the playback (sink) is timed by the output soundcard - two clock domains to synchronize. The correct way would be making the usb-gadget proper async soundcard, but that is quite a major complication.

Thanks for any info.


All times are GMT. The time now is 05:09 PM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 17.65%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2021 DragonByte Technologies Ltd.
Copyright ©1999-2021 diyAudio

Wiki