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)

phofman 6th August 2019 04:17 PM

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5874820.html#post5874820)
That is actually at least partly a myth. I use PyCharm as IDE which has a lot of refactoring functionality. Also python3 supports type hints which makes the guesswork for the IDE much easier.

I use PyCharm for my Python3 projects + all the (limited options for) hints available. I am a java guy and types are key. Even method renaming is unreliable since hints do not apply at all situations and pycharm is not a delphi prophet - it does half of renaming by search/replace which si very prone to errors.

I do not want to start a discussion about python (vs. static-typed languages like java), just wanted to say that refactoring a python project is rather (very) unreliable and any global change in the software hurts a lot.

dc655321 6th August 2019 04:35 PM

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5874834.html#post5874834)
I though about this as well already.

3) is out of the scope, at least at the moment. This opens a whole new can of worms and I don't feel confident enough to tackle this at the moment!

That's fair. And frankly, filter synthesis tooling does not interest me.
I can generate my own and there are existing tools others can use if they don't know the fundamentals.

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5874834.html#post5874834)
2) is a viable option, one more reason why I preferred wav files. They "know" their intended sample rate and the GUI can match that to the sample rate that pulseaudio is currently running at. If there's a mismatch the GUI can inform the user about that and even offer to resample the IR with soxr which then would lead into option 4).

I had the impression you were all about the UX/UI?
Do you not find 2) to be a significant user burden?

Another thing - perhaps your intentions were different from your wording, but one cannot simply "resample the IR". As I said in 4), it's not that simple. One must resample the input stream or reconstruct the filter targeting a different sampling rate.

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5874834.html#post5874834)
I briefly looked at rePhase as my filter design tool of choice. The .txt files it generates don't have any metadata at all, wav files do have at least the sampling frequency.

Btw. on more question: Why does rePhase need the FFT length? I thought that would have no impact on the IR?! Please enlighten me :)

AFAIK, rePhase is Windows-only software. That presents some obvious issues (but not insurmountable, of course).

As for requiring the FFT length:
For a filter specified as a certain curve in the frequency domain (magnitude and/or phase response), the length of the FFT will determine the resolution that the curve is sampled at. Longer FFT == finer resolution per frequency bin, if one views the magnitude of an FFT as a histogram of energy/freq. Note this is independent of the number of taps (coefficients) an FIR filter is spec'd with, and this parameter is also a resolution of sorts.

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5874834.html#post5874834)
PS: Should we open a new thread for the FIR filter/convolver implementation stuff?

Yes, please. Good idea. I already feel guilty for semi-spamming this one :guilty:

b_force 6th August 2019 06:10 PM

Quote:

Originally Posted by Tfive (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5874595.html#post5874595)
Well, if it's so simple - why don't you do it? ;)

To be clear: to serve HTTP request, you always need some kind of server. This requirement is not hard to fulfill, there's even a threaded http server class in python 3.7. But you have to define signals and slots in QT for all the http server callbacks because you are not allowed to block the QT main thread and also not allowed to access QT member data from outside the QT main thread. That's the backend side.

On the frontend side you need a fair bit of (JS/jquery/whatever) code for the UI to be interactive, you need AJAX callbacks to the http server etc. Not to mention that it should be modern, responsive UI design using bootstrap or similar to be useable with any device. The more I think of it, I would probably break the server for the frontend side of things out into maybe a pyramid project because then routing the requests is way more structured. Setting up a pyramid stack also takes time though.

All in all for just the parameter changing version I would predict somewhere around 20-30 hours at least. Most of times you simply double expected man hours to be somewhat near realistic :D And I was only talking about the "slim version" which cannot modify the signal routing of the crossover, i.e. delete/insert/connect filters. That would add a completely new level of complexity and thus man hours!

There's simply too much else going on in the background which I deem way more important ATM (measurement support is still cooking - more on that probably soon, and recently FIR support has made it at least into the serious research phase)...

Because I am not a full-time programmer, so it will cost me at least ten times more time.
I don't find 20-60 hours a lot of time, I easily spend that on just a tiny little PCB if I want to do it right.
The good thing is that it doesn't need to be finished by tomorrow, you can do it on the background for half a year.
Anyway, these are all details at this stage that aren't important yet.
Normally (the work I do on a regular basis), is to sit with a team and brainstorm a few ideas.

I just don't completely understand what is actually against making something with a lot of potential more accessible for more people?
Once again I absolutely don't mean that as bad critique, but just something I wonder about.

Because in the end there is absolutely nothing more important than user experience (in this case the interface). You can have an awesome idea, but if people don't want to use it because it's to "complicated" or to fiddly, the project goes on top of the pile of all these other projects collecting dust.
So sometimes you actually basically wasted all that time.

Measurement support for example, would be pretty low on the priority list by the simple fact that there are already tons of other programs (aka "competitors") who can do that perfectly fine.
So why putting time and effort in reinventing the wheel again? (and very likely that people would use their preferred measuring software anyway)

DarpMalone 6th August 2019 07:37 PM

Anyone know why PaXoverRack only see's (Built-In Audio Analog Mono) output?

I'm running Raspbian Buster (4.19.58-v7l+)
Raspberry Pi 4
7.1 HDMI Audio Extractor

Thanks,

skyunlimited 6th August 2019 08:40 PM

Quote:

Originally Posted by DarpMalone (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5875069.html#post5875069)
Anyone know why PaXoverRack only see's (Built-In Audio Analog Mono) output?

I'm running Raspbian Buster (4.19.58-v7l+)
Raspberry Pi 4
7.1 HDMI Audio Extractor

Thanks,

That seems to be an error in pulseaudio. I got the same error with Debian Buster on the pi 3+

phofman 7th August 2019 06:37 AM

Jürgen: Not only have you not received any help, now you are being told what you should have done better and how you should fix your priorities :-)

Guys, if you want something, learn and help. Excuses like "I am not a programmer", "It would take me too long" etc. are useless.

Tfive 7th August 2019 07:28 AM

Quote:

Originally Posted by DarpMalone (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5875069.html#post5875069)
Anyone know why PaXoverRack only see's (Built-In Audio Analog Mono) output?

I'm running Raspbian Buster (4.19.58-v7l+)
Raspberry Pi 4
7.1 HDMI Audio Extractor

Thanks,

IMHO this points to an error in the pulseaudio config. If there was no error, you wouldn't see the built in audio as "Mono"?! Maybe you could disable autospawn in /etc/pulse/client.conf, kill pulseaudio and start it up by using "pulseaudio -vv". Please the put the output into a pastebin so I can look at it...

Tfive 7th August 2019 07:38 AM

Quote:

Originally Posted by phofman (https://www.diyaudio.com/forums/pc-based/330273-pulseaudio-crossover-rack-multi-crossover-design-implementation-linux-post5875558.html#post5875558)
Jürgen: Not only have you not received any help, now you are being told what you should have done better and how you should fix your priorities :-)

Guys, if you want something, learn and help. Excuses like "I am not a programmer", "It would take me too long" etc. are useless.

  1. No worries, I'm self confident enough to stick to my priorities, mainly not because I'm blatantly ignorant but more because I write the software to fit MY needs in the first place. How egotistic! :D:D:D
  2. Bug reports and well formulated feature requests are always welcome, please use the gitlab tracker for that.
  3. There is no way anyways at the moment to deduce priorities from the number of people asking for it, because the numbers are more or less statistically irrelevant. Not to say your input is irrelevant!!! But my apache log shows 16 downloads for latest release 1.46, 2 of which are my own computers ;) So it's more or less a niche product anyways, at least until now. The only real usage report I got so far is from Ivo, using it as a fancy EQ, not even as a crossover :p

pelanj 7th August 2019 09:04 AM

The software is very nice and works for me - but until I can implement it in some kind of headless player controlled by a phone and some nice USB 10ch output sound card to feed my 4 way + ambient, I have no use for it. The interface and routing are much better than my current pair of t.racks DSPmini.

On the other hand, the tests with RPI and a cheap 8ch USB sound card went well. Still, a small fanless PC like HP T610 is on my list, as well as a soundcard with symmetrical outputs and supported by Linux.

phofman 7th August 2019 09:31 AM

Options:

1) Running with GUI on connected monitor first , configuring, configuring autologin/run after startup, disconnecting the monitor -> headless

2) Running with vnc client connecting to Xwindow vnc server

3) Running with X2go (well-configured VNC client/server)

4) Initial configuration via remote Xwindow (ssh -X) from other linux, then running in regular Xwindow without connected monitor


All times are GMT. The time now is 06:30 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