LADSPA filters for digital crossovers on the BBB

[francolargo]

I2S input to Botic

No need to change device tree

Using botic5 it should be enough to switch serializer into record mode by writing 'R' into its config slot. I've just updated missing doc on webpage.

For example (playback on data0, record on data1):
echo "IR--" > /sys/module/snd_soc_botic/parameters/serconfig

OK, I'm now working on I2S input to Botic. No output yet. Here is my checklist of steps taken:

1) Tested WM8804 board, Torx receiver, and SPDIF source in master mode (all good - sound from an Opus DAC), then configured transceiver to operate as slave, 16 bit I2S (all switches to '0').

2) Wired master, bit, and LR clocks plus ground from Cronus into 8804 transceiver. Wired Dout from transceiver to mcasp0_axr3 pin on Hermes header. (master clock signal does not look like bit clock signal - typical?)

3) Placed "MMMR" in /sys/module/snd_soc_botic/parameters/serconfig.

4) Installed snd-aloop using 'modprobe snd-aloop' and confirmed loopback device is active using 'arecord -L'.

5) edited asound.conf to include a default capture device:

  pcm.!default {
         type asym
         playback.pcm {
                 type plug
                 slave.pcm "filter"
         }
         capture.pcm {
                 type plug
                 slave.pcm "hw:1,0"
         }
 }

6) Created an I/O pipe with ecasound, which also serves to initiate the required clock output from Cronus to the transceiver. [ecasound -f:16,2,48000 -i:alsahw,1,0 -f:16,2,48000 -o:alsahw,0,0]

7) Initiate spdif input to the WM8804 transceiver.

All quiet...

Any thoughts on the missing link(s)?


TIA,

Frank

PS, Since the frequency of capture and play is fixed, one could just as well use ecasound to run the LADSPA filters. Ecasound can also run LV2 filters, which won't work in the old alsa type-ladspa plugin wrapper.

 

[miero]

Try to record directly from hw:0,0.

The snd-aloop is virtual soundcard loopback that is usually used to capture audio output from applications.

 

[francolargo]

Try to record directly from hw:0,0.

The snd-aloop is virtual soundcard loopback that is usually used to capture audio output from applications.

Thanks for this suggestion, Miero. I tried and did not have success. The reason that I tried the snd-aloop module is that there is otherwise no recognizable device from which to record. For example:

root@botic:/# arecord -L
null
    Discard all samples (playback) or generate zero samples (capture)
pulse
    PulseAudio Sound Server
default
filter
eq
delay
speaker
t-table

Perhaps 'default' could work if hw:0,0 is defined in asound.conf as the default capture source. But this is what I get when I try to initiate a capture (with output to file rather than device):

root@botic:/# ecasound -f:16,2,48000 -i:alsa,default -f:16,2,48000 -o /data/record.wav
(eca-chainsetup) Chainsetup "untitled-chainsetup"
(eca-chainsetup) "rt" buffering mode selected.
ERROR:  Connecting chainsetup failed: "Enabling chainsetup: AUDIOIO-ALSA: Unable to open ALSA--device for capture; error: No such file or directory"

# the same error results from this syntax:
root@botic:/# ecasound -f:16,2,48000 -i:alsahw,0,0 -f:16,2,48000 -o /data/record.wav

With the Loopback device enabled using snd-aloop, I see these possible capture devices:

root@botic:/# arecord -L
null
    Discard all samples (playback) or generate zero samples (capture)
pulse
    PulseAudio Sound Server
default
filter
eq
delay
speaker
t-table
sysdefault:CARD=Loopback
    Loopback, Loopback PCM
    Default Audio Device
dmix:CARD=Loopback,DEV=0
    Loopback, Loopback PCM
    Direct sample mixing device
dmix:CARD=Loopback,DEV=1
    Loopback, Loopback PCM
    Direct sample mixing device
dsnoop:CARD=Loopback,DEV=0
    Loopback, Loopback PCM
    Direct sample snooping device
dsnoop:CARD=Loopback,DEV=1
    Loopback, Loopback PCM
    Direct sample snooping device
hw:CARD=Loopback,DEV=0
    Loopback, Loopback PCM
    Direct hardware device without any conversions
hw:CARD=Loopback,DEV=1
    Loopback, Loopback PCM
    Direct hardware device without any conversions
plughw:CARD=Loopback,DEV=0
    Loopback, Loopback PCM
    Hardware device with all software conversions
plughw:CARD=Loopback,DEV=1
    Loopback, Loopback PCM
    Hardware device with all software conversions

In this case, ecasound can run using input from hw:1,0 but not from hw:0,0:

root@botic:/# ecasound -f:16,2,48000 -i:alsahw,1,0 -f:16,2,48000 -o:alsahw,0,0
**************************************************************************
*        ecasound v2.9.0 (C) 1997-2012 Kai Vehmanen and others    
**************************************************************************
(eca-chainsetup) Chainsetup "untitled-chainsetup"
(eca-chainsetup) "rtlowlatency" buffering mode selected.
(eca-chainsetup) Opened input "alsahw", mode "read". Format: s16_le, channels 2, srate 48000, interleaved.
(eca-chainsetup) Opened output "alsahw", mode "write". Format: s16_le, channels 2, srate 48000, interleaved.
- [ Connected chainsetup: "untitled-chainsetup" ] ------------------------
- [ Controller/Starting batch processing ] -------------------------------
- [ Engine - Driver start ] ----------------------------------------------

Again, I need some kind of process 'playing' in order to activate the clock outputs on Cronus that (presumably) time the WM8804 transceiver.

I also tried running the ecasound process in one ssh window and then using arecord in a separate ssh window:

root@botic:/data# arecord -f dat -d 15 -D hw:0,0 record.wav
arecord: main:722: audio open error: No such file or directory

So, I'm perplexed why no capture device seems to be associated with hw:0,0. Overall, probably any kind of 'PCM pipe' should work for this purpose. But ecasound is very flexible, well documented, and fairly easy to configure.

I worry that maybe the Cronus system clock signal may not be working. My old, slow analog oscilloscope (with a genuine CRT! - it was free ) merely shows the trace getting slightly wider on hookup, and nothing changes when a playback signal is initiated through Cronus. Whereas, playback obviously starts the other 2 clocks, and I can just barely resolve the bit clock. What frequency multiple is the master clock relative to the bit clock frequency?

Finally, thanks for your continued interest in this 'side-project' to Botic. If it works it might expand the uses for Botic/BBB in DIY audio appliances.

 

[phofman]

What does aplay -l (small l) say?

 

[miero]

Hmm, recording with Botic will not work, because I've not included all patches from my side-project into released version. I'll try to fix it in the next days.

 

[francolargo]

Thanks Miero!

Pavel,

root@botic:~# arecord -l
**** List of CAPTURE Hardware Devices ****
root@botic:~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Botic [Botic], device 0: external dac-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

 

[francolargo]

Today I tested the ALSA filter chain on DSD64 and DSD128 files. The DSD source files sound great via mpd into hw:0,0! However as expected, they don't filter via LADSPA. I also tried configuring mpd for DoP, and again, noise. [Actually DSD64->DoP was half music, half noise.] Thus, LADSPA filters running in ALSA are suitable for PCM format only.

 

[miero]

Haha, yes that was expected

DSD encoding is not processing friendly.

 

[phofman]

Thus, LADSPA filters running in ALSA are suitable for PCM format only.

Of course, they process PCM only. The DoP has a PCM format identifier, thus the chain accepts it, but ruins by converting to float and processing in the filters.

IMO MPD needs a separate alsa config section for dsd streams. The alsa output plugin could easily decide which config to use during its open call when the played-back format is known.

 

[soundcheck]

Just stepped over this thread. (phofman. I hope they pay you for your high level consulting )
I've been trying and running Richards filters, LADSPA, squeezelite+ecasound for quite some time. Quite nice and convenient.
(Can't understand why people still use MPD as base player)

However.
I'm wondering why you folks still want to go the IIR route instead of FIR? There's rePhase to make the filters, there's brutefir.



PS:
I'm running a Cubitruck btw. IMO one of the best boards out there. NO no BBB. I do also own PI-B+/PI2.
Then I'm running a RME Fireface UCX (modified power supply and USB filter) in class compliant mode (24/96 max).

 

[francolargo]

Just stepped over this thread. (phofman. I hope they pay you for your high level consulting )
I've been trying and running Richards filters, LADSPA, squeezelite+ecasound for quite some time. Quite nice and convenient.
(Can't understand why people still use MPD as base player)

However.
I'm wondering why you folks still want to go the IIR route instead of FIR? There's rePhase to make the filters, there's brutefir.

Welcome to the discussion, @soundcheck! Yes, @phofman has been very helpful!

Clearly, FIR is the standard we would like to eventually achieve, but using it with the current hardware probably means compromises elsewhere. Specifically, one of the goals behind the movement toward headless players has been to avoid any kind of resampling, hence we have Miero's nice Botic kernel and various clock-switching input options such as the TPA Cronus. Will the BBB run FIR filters? Yes, though BruteFIR reportedly gives poor results running in real time. Check out:
https://github.com/hzeller/folve
https://volumio.org/forum/dsp-with-raspberry-hifiberry-and-volumio-drc-folve-t672.html

Perhaps the current cubitruck has enough CPU for multichannel FIR! It would be interesting to know. Personally, I need to have much other 'audio fun' before I can enjoy my re-vamped 'main' system, so I can't mess with it now.

At the moment we are waiting for Miero to make changes in the Botic kernel so that the BBB will accept external I2S. When that becomes available, it is imaginable for the future that "slave BBB boards" receiving I2S could divide jconvolver DSP labor for crossover filters without forcing 44.1k material into a 48k frequency multiple. ...a BBB Sharc? Software and its implementation will become more dominant drivers of innovation, no? ...Botic is leading the way!

Having worked with the same high quality drivers through the years, I have some experiences with crossovers that might be useful here. First, simple is good - with IIR filters it is often better to roll off more gently vs. more sharply. Second, in a three-way, it is better to have the widest midrange band possible. Third, it is easy to assume that our drivers are perfect pistons but, believe me, they most likely are not - and their various flaws can be brought out (or diminished) by any number of digital issues. Finally, we all have different preferences, expectations and definitions for quality, which are fun to work on but complicates dialogs like this. I realized some years ago that in critical listening I was not paying attention to an important element of a great experience. Now when tweaking, I pay critical attention to the apparent 'space around the instruments' (among other things, of course) and signal phase figures into this. That kind of sensation, like enjoyment, is not an easy quality to discuss in places like this... But technical achievement is a fun topic that moves each of us toward our goals.

 

[miero]

At the moment we are waiting for Miero to make changes in the Botic kernel so that the BBB will accept external I2S.

Aaah, yes. Thanks for patience...

 

[soundcheck]

Yep.

The problem is that you guys accept lower quality compromises on the SW side, because you tied yourself up on a low steam BBB or similar ( and obviously a directly connected TP DAC) because of a clocking scheme.

I think that's not such a great idea. Considering the effort behind going multichannel-active, people should be made aware that they might end up at a bottleneck at one point.

For doing serious DSP (resampling+crossover+equalization+roomequalization) work there are IMO more appropriate platforms out there.

I'm running these ARM devices as streamers and let them resample at best.
I do also run a Cubitruck as LogiteMediaServer.
However. It's performance is not comparable to an e.g. Intel Core I5 server.

Just my 2 cents.

 

[miero]

You can mix those approaches together: Use your server for extreme DSP and then stream multi channel audio into BBB over Ethernet.

 

[soundcheck]

You can mix those approaches together: Use your server for extreme DSP and then stream multi channel audio into BBB over Ethernet.

Yep, That's basically what I said. The BBB with it's clocking scheme as a
stereo streamer might work quite well. No question.
How it performs on a multichannel Hirez stream over net is another question.

If you guys use MPD as base you'll be trapped on that side - I guess. MPD is not really a
client-server system like LMS and squeezelite. I'd have no idea how you'd "outsource" your DSP work.

I did run convolution on my powerful LMS server. However.
Multichannel DSP work will only work on the output of squeezelite locally.
squeezellite -> ecasound or squeezelite -> brutefir or squeezelite -> alsa.

 

[miero]

Yes, if you use squeezelite you'll be trapped on that side too... ;-)

You can easily stream multichannel audio via command line tools, here is an example script that uses SoX over SSH - http://bbb.ieero.com/botic1/bbbplay

It could be adapted to capture stream from Loopback card on the Linux PC and then DSP & stream to BBB.

 

[francolargo]

The BBB with it's clocking scheme as a
stereo streamer might work quite well. No question.

This is certainly what I am finding! ...and obviously, expecting heavy duty number crunching from a SoC is not plausible. This thread is about an 'adaptation' for the BBB and whether it is a good compromise.

I'd have no idea how you'd "outsource" your DSP work.

I did run convolution on my powerful LMS server. However.
Multichannel DSP work will only work on the output of squeezelite locally.
squeezellite -> ecasound or squeezelite -> brutefir or squeezelite -> alsa.

Perhaps another approach, at least in terms phase alignment, would be to stick with IIR filters in the BBB but in the server do a 'mirror-image' phase adjustment to be reversed by the chosen crossover package.

Having used IIR filters with no other 'tricks', I know they can give very pleasing results. My personal experience with room correction has not been so wonderful - better to treat the room! For me, best results from keeping it simple! Cheers!

 

[francolargo]

I did run convolution on my powerful LMS server.

By any chance was it the BruteFIR option? Apparently the 4.0 wrapper will swap filters to accommodate the sample rate of the source??? That seems pretty attractive for non- or minimal-resampling advocates. Considering all possible sources for phase misalignment in the acoustical environment (in addition to an IIR crossover), perhaps a single corrective stereo convolution on the server side (rePhase, etc.?) makes perfect sense.

[It will be a good while before I can test...]

 

[soundcheck]

I used brutefir in a custom-conversion version rule of LMS. Never used these plugins.
However automatic sample rate switching, was one of the weak spots of my solution.
Probably the plugin is the way to go.
However. I gave up on room equalization. My conclusion after numerous tries and filters (DRC) was (3-4 years ago): Yes very nice, clean, dynamic, 3-D. However. Low level information seemed to be gone. I left it alone. Perhaps there are better algorithms nowadays!?!?

 

[stijn001]

A while ago I compared two images on my NAS -> BBB ->(I2S) S03->DDDAC. One was Miero's Botic's image and one Squeezelite image (with my Synology NAS as the server). Same content and hardware.

I found MPD to sound better, less edgy/thin and more correct sounding. After that I stuck with MPD.