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)

Tfive 28th August 2019 09:17 AM

Quote:

Originally Posted by phofman (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5898272.html#post5898272)
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.

I had to dig a little to find it again. It's still just a suspicion that this might be the underlying cause (please also read the bug report contained in the source:
Code:

/* Called from I/O thread context */
static void sink_input_update_max_rewind_cb(pa_sink_input *i, size_t nbytes) {
    struct userdata *u;

    pa_sink_input_assert_ref(i);
    pa_assert_se(u = i->userdata);

    /* FIXME: Too small max_rewind:
    * 53709 – Filter sinks (and sources?) have too small max_rewind */
    pa_memblockq_set_maxrewind(u->memblockq, nbytes);
    pa_sink_set_max_rewind_within_thread(u->sink, nbytes);
}


Tfive 28th August 2019 09:18 AM

Quote:

Originally Posted by AllenB (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5898280.html#post5898280)
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.

OK, please open an issue @ gitlab, so I won't forget this request.

Overlays will be worked on in any case, as measurement support moves on.

phofman 28th August 2019 09:23 AM

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5898436.html#post5898436)
It's still just a suspicion that this might be the underlying cause (please also read the bug report contained in the source

Uff, that is too low-level PA stuff for me :-)

Tfive 28th August 2019 09:26 AM

Quote:

Originally Posted by phofman (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5898428.html#post5898428)
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.

Unfortunately I don't :whazzat:

I asked a very similar question already on the mailing list, no reply at the time. I suggest you ask yourself and keep us posted. I could setup a small test bed with my two soundcards on the laptop for you though, capture device would be an ASUS Xonar U5, adaptive mode, playback the internal Intel HD Audio. Would that help you? Btw "pacmd list sinks" lists the used resampling method, maybe in this case the loopback module would take care of the resampling?

Btw. very interesting news on the usb audio gadget driver and the concept of the "intelligent soundcard".

phofman 28th August 2019 09:49 AM

Thanks. The module-loopback does indeed drop/insert samples automatically pulseaudio/module-loopback.c at master * pulseaudio/pulseaudio * GitHub . A rudimentary method, but OK for non-critical purposes. But you do not use this module in your setup, right?

A proper adaptive resampling like in module rtp would be much better :-) pulseaudio/module-rtp-recv.c at master * pulseaudio/pulseaudio * GitHub


Testing the current situation would definitely help, with your code used, without the resampling module-loopback. But detecting the buffer inconsistencies may be a bit complicated since they may occur scarcely (usually the clock freqs will differ only very little).

Tfive 28th August 2019 10:11 AM

I think you read the code a bit wrong ;)

There's a comment near the end of the function:
/* Drop or insert samples if fast_adjust_threshold_msec was specified and the latency difference is too large. */

You disregarded the if. If fast_adjust_threshold_msec is not specified, the early return doesn't catch and the rest of the function calculates the adjusted sample rate and sets it on the sink input, so the following sink can resample accordingly. At least that's how I read it at a glance.

AllenB 28th August 2019 10:13 AM

I just want to say that I'm having a lot of fun with this. I'm hoping I can take it further.

My measurement and crossover designing tools are on a different system and I dual boot to them. This has been setting limits but I'm holding out for better.

I don't know whether a USB card is close in timing to an onboard card. I started using it today and results are promising.

phofman 28th August 2019 10:26 AM

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5898474.html#post5898474)
You disregarded the if. If fast_adjust_threshold_msec is not specified, the early return doesn't catch and the rest of the function calculates the adjusted sample rate and sets it on the sink input, so the following sink can resample accordingly. At least that's how I read it at a glance.

You are absolutely right. That is great news. But only for module-loopback users :-) Is there any way to use such code (calculating and setting current rate to the stream, letting PA resample automatically) in your project?

phofman 28th August 2019 10:36 AM

Unfortunately I do not see the method pa_sink_input_set_rate used for adaptive resampling in any standard PA input module, only in loopback, combine, and echo-cancel.

Search * pa_sink_input_set_rate * GitHub

Tfive 28th August 2019 05:14 PM

Quote:

Originally Posted by phofman (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5898494.html#post5898494)
Unfortunately I do not see the method pa_sink_input_set_rate used for adaptive resampling in any standard PA input module, only in loopback, combine, and echo-cancel.

Actually adaptive resampling is only ever needed in case of loopback or combine, where the hardware clocks of the source and sink (in case of loopback) or the two sinks (in case of combine) may differ slightly over time. So that's why there is only code in these modules. This way using two soundcards with different clocks (not adaptive) should also work with PaXoverRack as the splitter is modeled by a module-combine-sink internally.

Quote:

Originally Posted by phofman (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5898489.html#post5898489)
You are absolutely right. That is great news. But only for module-loopback users :-) Is there any way to use such code (calculating and setting current rate to the stream, letting PA resample automatically) in your project?

If you use a different sample rate in your player than the one that pulseaudio runs at it will always resample accordingly but this doesn't need to be adaptive, instead it is performed with a fixed resampling ratio, for example playing a 44.1kHz file while pa runs at 96kHz. After all the player (source) is synced to the sink input's clock. This happens completely transparently, the only thing to configure is the resampler to be used internally. I set it to soxr-vhq (vhq being very high quality), though I have to admit that I don't hear any difference to speex-float-2, which is the not-very-high-quality default resampler.

Btw speaking of "using such code in my project" is probably a tad incorrect (;)), after all the hard work is all done by pulseaudio itself, I'm just configuring a bunch of pulseaudio modules and then persisting their config in the default.pa file.


All times are GMT. The time now is 12:09 AM.


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

Wiki