• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

LADSPA filters for digital crossovers on the BBB

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
I put my AV receiver on direct (no downmixing), and played the 6 channel wav file (with only two speakers). I hear some of the sounds, not all. When I switch the AVR to downmix, I hear all sounds/channels. The AVR display also says multichannel input. For totally definitive judgement, I should hook up more loudspeakers, but I think it's fairly certain that multichannel over HDMI now works for me. Hurray.

I tried playing music just through ALSA. 16 bit/44.1kHz works without trouble on both Audacious and VLC mediaplayers. 24/96 works well on Audacious, but sounds distorted on VLC. I looked at some things and noticed that I changed max sample rate on only one line in the modified driver. There is another line elsewhere that I didn't change, maybe that matters here. I will change that and recompile.

I also tried out Jack with Audacious (set to Jack output). It gives very strange distorted sound. It's slower, it stutters and pitch seems lower. I tried out some things, listened very carefully, it seems that it plays the music in little chunks and that playback speed alternates between fast and slow. An interesting situation.

I'll try modifying the driver some more and see what happens with VLC.
 
Last edited:
Member
Joined 2007
Paid Member
I also tried out Jack with Audacious (set to Jack output). It gives very strange distorted sound. It's slower, it stutters and pitch seems lower. I tried out some things, listened very carefully, it seems that it plays the music in little chunks and that playback speed alternates between fast and slow. An interesting situation.

I'll try modifying the driver some more and see what happens with VLC.

Lower pitch usually indicates a sample rate mis-match. Stuttering and clicking, etc. often indicate an inadequate buffer size. I'd change the buffers first... Glad to read you are making progress!

F.
 
I completely removed jack and qjackctl. I added the autostatic repo (audio software patched specifically for the Pi) and re-installed. Raspbian should come with working jack etc, but you never know. I also saw some advised buffer/frame settings for Jack with onboard sound and used those. I started out with 44.1kHz samplerate.

Straight away I had my 8 channels output back. Excellent sound with regular 16/44.1 files. I tried out some eq, on the fly, worked great. Playing a 24/96 file gave no sound. Then I changed sample rate in Jack, which gave distorted sound. I was getting Xruns. Changing settings reduced the distortion, so I seem to be on the right track.

It's going faster than I thought, actually.
 
I am getting good ALSA sound from VLC now, turns out I needed to select " enable audio" and "enable real-time" in preferences.

Next I started playing with Jack settings. I get good " pass-through" sound over Jack, no processing, up to 192 kHz. Good. A simple EQ plugin (stereo, not multichannel) worked well at 44.1kHz, not so well at 192kHz at the settings I had at that point, I later got it working very well. It's time to go to bed now, another night I will dpcument my settings here and try out multichannel EQ/DSP.

Neat!
 
From miniDSP to Alsa

Hi folks. Fascinating thread. Thanks for sharing all this wealth of knowledge.
In spite of being a software engineer, my in-depth knowledge on audio leaves much to be desired, so I'm sorry if these questions sound kind of silly.

I have a pair of Linkwitz Labs LX521.4 speakers (best speaker system I've ever heard). They use the miniDSP 8x10 HD as a processor. I figured I'd try to replace it with a combination of LADSPA filters using an Asus Xonar U7 card and repurposing the channels. Since the LX is already digital, all I should be able to do is to copy the parameters and voila, instant replacement.

However, the configuration in question uses some specific attributes that I don't know how to translate to LADSPA filters. I'm lost on a few: Bypass, Invert, Peak, LR12 and LR24. All the others (Low/high pass/shelf, parametric equalization, delay) have direct equivalents so it should be easy.

Does anyone know how to express these parameters with LADSPA filters? Thanks!
 
Member
Joined 2007
Paid Member
Greetings!

Your project should be straightforward at the level of ALSA's programmable user space. The real trick, IMHO, will be to improve on the performance of the miniDSP. Avoiding all non-integral resampling of source file frequencies is worth the effort, The ALSA task need not resample, and should generally apply over a range of hardware and CPU solutions.

Here is some homework: check out Richard Taylor's approach to your speakers (but don't jump to implement b/c ecasound runs at a fixed freq.)*

http://rtaylor.sites.tru.ca/2013/03/20/lx521-with-software-dsp/

Next, check out Charlie Laub's filter set - the preferred package for customized curves:

http://audio.claub.net/LADSPA-plugins.html

After this reading, check back and we can answer any questions before you take the plunge. For sure, you need to have your 7.1 DAC running from the intended Linux platform before trying to debug ALSA filter sets!

Regards,

Frank

*footnote: Richard correctly pointed out to me that IF one is willing to devote much development effort and CPU to resampling, it can be nearly transparent. HQ player is one such filtration software package with enthusiastic devotees. That takes you well beyond available LADSPA offerings in filter sophistication - all for a price, of course...

Sent from my iPad using Tapatalk HD
 
Hi folks. Fascinating thread. Thanks for sharing all this wealth of knowledge.
In spite of being a software engineer, my in-depth knowledge on audio leaves much to be desired, so I'm sorry if these questions sound kind of silly.

I have a pair of Linkwitz Labs LX521.4 speakers (best speaker system I've ever heard). They use the miniDSP 8x10 HD as a processor. I figured I'd try to replace it with a combination of LADSPA filters using an Asus Xonar U7 card and repurposing the channels. Since the LX is already digital, all I should be able to do is to copy the parameters and voila, instant replacement.

However, the configuration in question uses some specific attributes that I don't know how to translate to LADSPA filters. I'm lost on a few: Bypass, Invert, Peak, LR12 and LR24. All the others (Low/high pass/shelf, parametric equalization, delay) have direct equivalents so it should be easy.

Does anyone know how to express these parameters with LADSPA filters? Thanks!

A quick search "minidsp lr12" seems to suggest that LR 12 or LR 24 are Linkwitz Riley filters with 12dB or 24 dB per octave slopes. That would equate to 2nd order and 4th order resp.

J.
 
Member
Joined 2007
Paid Member
Correct on the LR 2nd and 4th order filters. As well, I believe...
a) 'bypass' is a routing mechanism to maintain a channel without altering the content
b) 'invert' is simply phase inversion, easily done with Charlie's filters
c) 'peak' I'm unsure of w.r.t. the LX521 - could be simple frequency-specific attenuation or amplification [an EQ function], or perhaps it is a more general compressor. Either way, LADSPA plugs have you covered. :)

Cheers,

Frank
 
Greetings! Thought I'd do a little update of small lessons learned.

Turns out that assignable channels om my AV receiver are not in use when playing in direct/pure mode (assignable as in can be added surround, front height, or wide front or bi-amping of fronts). I attached speakerwire to these assignable channels, because they were easy to reach. I kept having issues with some of my filtered channels being downmixed, until I put the wires on the surround channels.

So now I know that my 7.1 AVR is more of a 5 channel direct/pure amp with a filtered sub-out. So, sticking to a pair of two-way loudspeakers in this situation.

The stuttering issue, and lower pitch, seems to be caused by the re-sampling process eating up too much processor resources. If I choose a different resampling algorithm that is lighter, it reduces or disappears. Perhaps there is also a conflict between Jack and VLC, in the sense that they have some real-time priority settings and this might not work too well. Maybe if I untick real-time in VLC, it would also help.

The Jack settings are a bit finnicky. I did lots of iterative tests, had a whole table in a spreadsheet, with various sample-rates, buffer and frame settings, and notes about whether it would run and if it had xruns or not. BUT... this is with just Jack started. Load plugins and filters, the results change. Play a media file, the results change. Change resampling... Well, you know. So it requires finetuning after each change to the system. It has proven possible to find jack settings for 96khz that has almost no xruns and will run 24/7 for weeks without failing. I think many of the xruns that I do see, are related to my actions/using the graphic interface to see if everything is still running.

I have an extra pi now and am looking into setting a master-slave relationship in Jack between the two pi's. So that one pi plays the media into jack, jack transports it over the wired network to the other pi where processing is done. Jack then sends it back to the original pi and to the AVR over HDMI. That way, I hope the processing pi is most robust and the playing pi can be set to optimal re-sampling settings etc.

Right now, it simply works, but it is not usable enough for the family living room. It would be cool if the player could run Kodi (the next release will probably be able to play stuff like Netflix as well) and run Jack underneath to patch it to the DSP pi. But that is perhaps another project entirely. As it stands, this is turning into a more music oriented DSP.
 
Oh, and a question about the kernel hacking. I see that in the kernel, the bitrate is also defined. We change the samplerate and number of channels, but not the bitrate. Can we also change that and what would be the right code for that? Simply changing 16 to 24? Or is it more complicated than that? If you check the capability of the HDMI hardware, it says 24/192 is possible, but as far as I can tell the kernel as it is now puts out 16/192.
 
Member
Joined 2007
Paid Member
The stuttering issue, and lower pitch, seems to be caused by the re-sampling process eating up too much processor resources. If I choose a different resampling algorithm that is lighter, it reduces or disappears. Perhaps there is also a conflict between Jack and VLC, in the sense that they have some real-time priority settings and this might not work too well. Maybe if I untick real-time in VLC, it would also help.

Thanks for the update! I imagine that VLC needs as much priority as it can get, so I would expect real time status to be most satisfactory. If you can increase the buffer size that might also help. Which program is initiating the resampling? If you can eliminate that processing you will definitely save CPU. With HDMI out, shouldn't any reasonable sample rate be acceptable? The LADSPA filters adapt to changes in sample rate without problem if run within ALSA's user space. If JACK is causing resampling (which I doubt), I would consider using Alsa instead, and just suffering through the process of managing the various streams.
I have an extra pi now and am looking into setting a master-slave relationship in Jack between the two pi's. So that one pi plays the media into jack, jack transports it over the wired network to the other pi where processing is done. Jack then sends it back to the original pi and to the AVR over HDMI. That way, I hope the processing pi is most robust and the playing pi can be set to optimal re-sampling settings etc.

THAT would be very cool if you get it working! To my knowledge it would be a first...
Right now, it simply works, but it is not usable enough for the family living room.
I know how the complexity of these systems seems to grow exponentially. :D I solved this in my system using a program called NetIO, which allows any iOS or android device to become a remote control. Then using python scripts, changing many operating parameters at once is as simple as a button click. I even use it with I2C to address my DAC chips and control volume at that point in the chain. With NetIO there would be no need to activate the system GUI. I have examples of script code for my BBB on GitHub, and there is a thread here Control of BBB-based audio appliances

Finally, regarding your other question, I have never tweaked a kernel so can not help.

Cheers,

Frank
 
Last edited:
If JACK is causing resampling (which I doubt), I would consider using Alsa instead, and just suffering through the process of managing the various streams.

Jack runs on a set sample-rate. My biggest reason for using Jack, is the graphic interface. I build loudspeakers and to "code" a crossover and EQ together every iteration is not the fun part of playing with this. The Hypex and MiniDSP interfaces are what you want if you are a loudspeaker hobbyist first. Jack is messy to get going on a pi (for my and my particular lack of knowledge and learning curve), but it sets up in minutes on a x86 linux computer and after that fooling around with channels connections and plugins is very intuitive and easy.

Jack also tightly controls synchronisation between channels and processes, even over network connections. It is actually used for instance in studio situations with small silent clients in the studio/control room and the big noisy recording/processing computer with hard disks and fans in a cupboard or the basement. It has that level of reliability and tight sync.

Really, after what I learned, next time I would advise somebody else to but an Intel NUC and run KXstudio on it. Everything ready to roll, Jack and plugins and plenty of computing power left to play and transcode media. But so far this has been so much fun and so educational. A hobby of its own.

THAT would be very cool if you get it working! To my knowledge it would be a first...

Error using jackd on RPI3 - Raspberry Pi Forums

Note you could go so far as to split all channels and have a whole pi per channel available for DSP. Or string a number of pi's to do more channels. Convolution with LOTS of taps. I mean that's absurd at some point, but this does open up possibilities.

I know how the complexity of these systems seems to grow exponentially. :D I solved this in my system using a program called NetIO, which allows any iOS or android device to become a remote control.

Very interesting. I'll check that out.

If the next version of Kodi does all that is planned, that would be great, has some very usable remote control apps.

Finally, regarding your other question, I have never tweaked a kernel so can not help.

No problem, will keep looking. :)
 
Member
Joined 2007
Paid Member
Pretty interesting stuff! Your approach has quite a different focus from others I've seen involving the RPi. Both it and the BBB have the ability to input an external master clock. By selecting the appropriate frequency multiple, no resampling is necessary in the process of rendering different music files to real time. The sonic benefits of that are well recognized. The Botic kernel that I use switches between two different oscillators depending on the native frequency of the particular file being played. But you are gaining other attributes that suit your system, so why not? Proost! :)
 
Just a very small update: there is a kernel hack at github for multichannel over HDMI *and* higher sample-rates and bit-rates. I recompiled with that and get fewer issues with xruns etc in Jack. DSP load is a bit lower as well, it seems. I see there are a few more changes here and there in the kernel, annotated stating it's necessary for higher sample-rates. I am guessing the simple hack really only facilitated the multichannel part and that a high sample-rate set in Jack (higher than 48kHz) could not be output over HDMI and had to be re-sampled again. The hardware is more capable than we think, but the software/firmware is not there yet. The hobby space. :)

PCM sound on HDMI output: Support higher sampling rates up to 192 kHz, 24 bit depth, 5.1 channels by soundg33k * Pull Request #1834 * raspberrypi/linux * GitHub
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.