LADSPA filters for digital crossovers on the BBB

phofman · 2015-07-28 6:28 am

francolargo said:
Provisional success playing available files: 44.1, 88.2 & 96 kHz...

Great, congrats.

I have no idea if these period and buffer times are best but they work for all three file types.

They have no impact on sound, I would keep the combination which works with all samplerates. IMO LADSPA plugins together with your rather limited card (in terms of setup variability) are very picky. It is actually quite difficult for the chain to pick correct buffer size automatically in this situation.

I wonder if this is a concern considering that sample rates are increased by a factor of two.

IMO it is. Every samplerate conversion involves brickwall filter. I would try if your CPU power can handle the better samplerate algorithms. Look here https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#High_quality_resampling for explanation. Can you install the speex library/package?

I have not yet finished a project using the highly efficient libsoxr library in the alsa rate plugin Using libsoxr-lsr in Alsa Rate Plugin with LD_PRELOAD | Blog IVITERA a.s. It works but there are sometimes clicks as alsa rate plugin assumes too much about the resampling libraries (not working correctly with flushes).

That conversion was put there by alsa, you don't find it in asound.conf.

As I already said, it is performed by the plug in your device "speaker". Your chain runs at 44100, but your soundcard offers 88200 only. The final plug must resample to comply. If you convinced your card to accept 44100/4 channels, there would be no resampling.

I see that alsa also initiates an integer->float conversion that is not in asound.conf.

Quoting alsa.opensrc.org :

The usage of the plug plugin is important because LADSPA plugins only can han handle FLOAT data. Most sound data is usually saved as some sort of Integer data..

Again, it is necessary and we should praise the nice plug plugin for taking care of all the necessary conversions automatically.

francolargo · 2015-07-28 2:42 pm

phofman said:
Every samplerate conversion involves brickwall filter. I would try if your CPU power can handle the better samplerate algorithms. Look here https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#High_quality_resampling for explanation. Can you install the speex library/package?

I believe the speex package is installed.

Code:

find -iname "*speex*"
./usr/lib/arm-linux-gnueabihf/libspeex.so.1.5.0
./usr/lib/arm-linux-gnueabihf/libspeex.so.1

phofman said:
As I already said, it is performed by the plug in your device "speaker". Your chain runs at 44100, but your soundcard offers 88200 only. The final plug must resample to comply. If you convinced your card to accept 44100/4 channels, there would be no resampling.

I suspect some different reason for resampling. Certainly, the 'sound card' can handle 44.1!
Here I have played the same track three different ways: a) using aplay with hw:0 output, b) using SoX with default output (yes, it did engage the crossover), and c) with mpc. Playing with squeezelite gives the same result as with mpc - 2X upsample.

Code:

aplay...
root@botic:/# cat /proc/asound/Botic/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5513
buffer_size: 22052

SoX play...
root@botic:/# cat /proc/asound/Botic/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 4
rate: 44100 (44100/1)
period_size: 1024
buffer_size: 8192

mpc
root@botic:/# cat /proc/asound/Botic/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 4
rate: 88200 (88200/1)
period_size: 113
buffer_size: 226

SoX is showing us that the up sampling is not always necessary. Sound-wise, I hear no audible differences among them. So I rather doubt that the final 'upsample' is doing any real interpolation. But I would certainly be willing to specify a better resampler just in case some actual math is happening.

Cheers!

phofman · 2015-07-28 7:53 pm

francolargo said:
I believe the speex package is installed.

Well then define the defaults.pcm.rate_converter as described in that link about alsa resampling. If it fails, libasound was not compiled with speex enabled. But I doubt that.

I suspect some different reason for resampling. Certainly, the 'sound card' can handle 44.1

The reason for resampling is simple - the plug plugin asks the soundcard driver - give me the nearest samplerate you can do under these conditions (buffer/period sizes, channel count, 44100). And the soundcard driver returns 88200. The plug plugin accepts everything since it knows it can comply - by resampling.

If your card can play 44100/4, find out with

Code:

aplay -v --mmap -D plughw:0 some-44100-4channels-32bit.wav

The 4-channel 32bit wav can be easily prepared with sox - look at sox examples/tutorials on internet. Always run sox with the -V (debug) option so that you know exactly what it is doing (just like aplay, only capital -V).

If the debug aplay output reports resampling, specify in aplay parameters the buffer/period sizes sox reports for 44100/4 playback:

Code:

period_size: 1024
buffer_size: 8192

If the soundcard again insist on 88200, we will investigate further. But I do not see any reason why it should offer 88200 when in sox under the same parameters the card offers 44100.

It can be that for those short buffers/periods the card can only offer 88200, it has to be troubleshooted.

So I rather doubt that the final 'upsample' is doing any real interpolation. But I would certainly be willing to specify a better resampler just in case some actual math is happening.

If the plug plugin reports resampling, it is resampling, using the algorithm it says.

francolargo · 2015-07-29 12:23 am

First, you rock! Again, thanks for your interest in this problem. ..and it is rewarding for me to be learning so much in the process!

phofman said:
Well then define the defaults.pcm.rate_converter as described in that link about alsa resampling. If it fails, libasound was not compiled with speex enabled. But I doubt that.

I did not have the speexrate package installed after all, so I installed Libasound2 and then 'speexrate' became the automatic default for alsa. This raised the CPU demand on the crossover to unacceptable levels. Lots of data underruns above 44.1kHz. ...so that was disappointing.

I also decided to set up better in order to hear the sound quality, so now I am listening directly to the DACs through my 'reference' headphones. With these, I do hear a difference in performance depending on the filter. The speexrate filter is good (at 44.1), but as expected, the linear interpolator is down a little bit in terms of quality & clarity.

phofman said:
If your card can play 44100/4, find out with

Code:

aplay -v --mmap -D plughw:0 some-44100-4channels-32bit.wav

If the soundcard again insist on 88200, we will investigate further. But I do not see any reason why it should offer 88200 when in sox under the same parameters the card offers 44100.

I made a 4 channel .wav file as you suggested and sent it to hw:0 using aplay. The 'card' should have 8 channels active. Result was no up sampling:

Code:

root@botic:/data# aplay -v --mmap --period-size=1024 --buffer-size=8192 -D hw:0,0 Track1.wav
Playing WAVE 'Track1.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Channels 4
Hardware PCM card 0 'Botic' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 4
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 8192
  period_size  : 1024
  period_time  : 23219
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 8192
  stop_threshold   : 8192
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
mmap_area[0] = 0xb6cc8000,0,64 (16)
mmap_area[1] = 0xb6cc8000,16,64 (16)
mmap_area[2] = 0xb6cc8000,32,64 (16)
mmap_area[3] = 0xb6cc8000,48,64 (16)

...and hw_params

root@botic:/# cat /proc/asound/Botic/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 4
rate: 44100 (44100/1)
period_size: 1024
buffer_size: 8192

Here is the debug info from using SoX to send two channel files to the default crossover filters. No up sampling and none at 88.2 nor at 96kHz - all hw_paraqms report period=1024, buffer=8192!

Code:

root@botic:/data# play Cafrune1.wav

Cafrune1.wav:

 File Size: 24.2M     Bit Rate: 1.41M
  Encoding: Signed PCM    
  Channels: 2 @ 16-bit   
Samplerate: 44100Hz      
Replaygain: off         
  Duration: 00:02:17.37  

In:7.78% 00:00:10.68 [00:02:06.69] Out:471k  [-=====|======] Hd:0.3 Clip:0    
Aborted.
root@botic:/data# play -V Cafrune1.wav
root@botic:/data# play -v.4 -V Cafrune1.wav
play:      SoX v14.4.1
play INFO formats: detected file format type `wav'

Input File     : 'Cafrune1.wav'
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:02:17.37 = 6058225 samples = 10303.1 CDDA sectors
File Size      : 24.2M
Bit Rate       : 1.41M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
Level adjust   : 0.4 (linear gain)


Output File    : 'default' (alsa)
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:02:17.37 = 6058225 samples = 10303.1 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

play INFO sox: effects chain: input        44100Hz  2 channels
play INFO sox: effects chain: output       44100Hz  2 channels

and...

root@botic:/# cat /proc/asound/Botic/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 4
rate: 44100 (44100/1)
period_size: 1024
buffer_size: 8192

Using aplay with the SoX parameters, it changes them to a 4/1 rather than an 8/1 ratio, and up sampling occurs:

Code:

root@botic:/data# aplay -v --mmap --period-size=1024 --buffer-size=8192 -D default Cafrune1.wav
Playing WAVE 'Cafrune1.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Plug PCM: Route conversion PCM (sformat=S16_LE)
  Transformation table:
    0 <- 0
    1 <- 1
    2 <- none
    3 <- none
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 2
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 23219
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 4096
  stop_threshold   : 4096
  silence_threshold: 0
  silence_size : 0
  boundary     : 536870912
Slave: Linear Integer <-> Linear Float conversion PCM (FLOAT_LE)
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 4
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 16
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 23219
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 4096
  stop_threshold   : 4096
  silence_threshold: 0
  silence_size : 0
  boundary     : 536870912
Slave: LADSPA PCM
  Playback:
    Policy: none
    Filename: /usr/local/lib/ladspa/RTlr4lowpass.so
    Plugin Name: RT LR4 lowpass
    Plugin Label: RTlr4lowpass
    Plugin Unique ID: 9020
    Instances:
      Depth: 0
         InChannels: 0
         InPorts: 1 "Input"
         OutChannels: 1
         OutPorts: 2 "Output"
    Audio input port bindings:
      0 -> 1
    Control input port initial values:
      0 "Frequency (Hz)" = 150.00000000
    Audio output port bindings:
      0 -> NONE
      1 -> 2
    Policy: none
    Filename: /usr/local/lib/ladspa/RTlr4hipass.so
    Plugin Name: RT LR4 highpass
    Plugin Label: RTlr4hipass
    Plugin Unique ID: 9021
    Instances:
      Depth: 1
         InChannels: 0
         InPorts: 1 "Input"
         OutChannels: 0
         OutPorts: 2 "Output"
    Audio input port bindings:
      0 -> 1
    Control input port initial values:
      0 "Frequency (Hz)" = 150.00000000
    Audio output port bindings:
      0 -> 2
    Policy: none
    Filename: /usr/local/lib/ladspa/RTlr4lowpass.so
    Plugin Name: RT LR4 lowpass
    Plugin Label: RTlr4lowpass
    Plugin Unique ID: 9020
    Instances:
      Depth: 2
         InChannels: 1
         InPorts: 1 "Input"
         OutChannels: 3
         OutPorts: 2 "Output"
    Audio input port bindings:
      0 -> NONE
      1 -> 1
    Control input port initial values:
      0 "Frequency (Hz)" = 150.00000000
    Audio output port bindings:
      0 -> NONE
      1 -> NONE
      2 -> NONE
      3 -> 2
    Policy: none
    Filename: /usr/local/lib/ladspa/RTlr4hipass.so
    Plugin Name: RT LR4 highpass
    Plugin Label: RTlr4hipass
    Plugin Unique ID: 9021
    Instances:
      Depth: 3
         InChannels: 1
         InPorts: 1 "Input"
         OutChannels: 2
         OutPorts: 2 "Output"
    Audio input port bindings:
      0 -> NONE
      1 -> 1
    Control input port initial values:
      0 "Frequency (Hz)" = 150.00000000
    Audio output port bindings:
      0 -> NONE
      1 -> NONE
      2 -> 2
  Capture:
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_NONINTERLEAVED
  format       : FLOAT_LE
  subformat    : STD
  channels     : 4
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 32
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 23219
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 4096
  stop_threshold   : 4096
  silence_threshold: 0
  silence_size : 0
  boundary     : 536870912
Slave: LADSPA PCM
  Playback:
    Policy: none
    Filename: /usr/lib/ladspa/delay.so
    Plugin Name: Simple Delay Line
    Plugin Label: delay_5s
    Plugin Unique ID: 1043
    Instances:
      Depth: 0
         InChannels: 1
         InPorts: 2 "Input"
         OutChannels: 1
         OutPorts: 3 "Output"
    Audio input port bindings:
      0 -> NONE
      1 -> 2
    Control input port initial values:
      0 "Delay (Seconds)" = 0.00120000
      1 "Dry/Wet Balance" = 1.00000000
    Audio output port bindings:
      0 -> NONE
      1 -> 3
    Policy: none
    Filename: /usr/lib/ladspa/delay.so
    Plugin Name: Simple Delay Line
    Plugin Label: delay_5s
    Plugin Unique ID: 1043
    Instances:
      Depth: 1
         InChannels: 3
         InPorts: 2 "Input"
         OutChannels: 3
         OutPorts: 3 "Output"
    Audio input port bindings:
      0 -> NONE
      1 -> NONE
      2 -> NONE
      3 -> 2
    Control input port initial values:
      0 "Delay (Seconds)" = 0.00120000
      1 "Dry/Wet Balance" = 1.00000000
    Audio output port bindings:
      0 -> NONE
      1 -> NONE
      2 -> NONE
      3 -> 3
    Policy: none
    Filename: /usr/lib/ladspa/delay.so
    Plugin Name: Simple Delay Line
    Plugin Label: delay_5s
    Plugin Unique ID: 1043
    Instances:
      Depth: 2
         InChannels: 0
         InPorts: 2 "Input"
         OutChannels: 0
         OutPorts: 3 "Output"
    Audio input port bindings:
      0 -> 2
    Control input port initial values:
      0 "Delay (Seconds)" = 0.00000000
      1 "Dry/Wet Balance" = 0.00000000
    Audio output port bindings:
      0 -> 3
    Policy: none
    Filename: /usr/lib/ladspa/delay.so
    Plugin Name: Simple Delay Line
    Plugin Label: delay_5s
    Plugin Unique ID: 1043
    Instances:
      Depth: 3
         InChannels: 2
         InPorts: 2 "Input"
         OutChannels: 2
         OutPorts: 3 "Output"
    Audio input port bindings:
      0 -> NONE
      1 -> NONE
      2 -> 2
    Control input port initial values:
      0 "Delay (Seconds)" = 0.00000000
      1 "Dry/Wet Balance" = 0.00000000
    Audio output port bindings:
      0 -> NONE
      1 -> NONE
      2 -> 3
  Capture:
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_NONINTERLEAVED
  format       : FLOAT_LE
  subformat    : STD
  channels     : 4
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 32
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 23219
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 4096
  stop_threshold   : 4096
  silence_threshold: 0
  silence_size : 0
  boundary     : 536870912
Slave: Plug PCM: Linear Integer <-> Linear Float conversion PCM (S32_LE)
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_NONINTERLEAVED
  format       : FLOAT_LE
  subformat    : STD
  channels     : 4
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 32
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 23219
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 4096
  stop_threshold   : 4096
  silence_threshold: 0
  silence_size : 0
  boundary     : 536870912
Slave: Rate conversion PCM (88200, sformat=S32_LE)
Converter: linear-interpolation
Protocol version: 10002
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 4
  rate         : 44100
  exact rate   : 44100 (44100/1)
  msbits       : 32
  buffer_size  : 4096
  period_size  : 1024
  period_time  : 23219
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1024
  period_event : 0
  start_threshold  : 4096
  stop_threshold   : 4096
  silence_threshold: 0
  silence_size : 0
  boundary     : 536870912
Slave: Hardware PCM card 0 'Botic' device 0 subdevice 0
Its setup is:
  stream       : PLAYBACK
  access       : MMAP_INTERLEAVED
  format       : S32_LE
  subformat    : STD
  channels     : 4
  rate         : 88200
  exact rate   : 88200 (88200/1)
  msbits       : 32
  buffer_size  : 8192
  period_size  : 2048
  period_time  : 23219
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 2048
  period_event : 0
  start_threshold  : 8192
  stop_threshold   : 8192
  silence_threshold: 0
  silence_size : 0
  boundary     : 1073741824
  appl_ptr     : 0
  hw_ptr       : 0
mmap_area[0] = 0xff15a8,0,32 (16)
mmap_area[1] = 0xff15a8,16,32 (16)

phofman said:
If the plug plugin reports resampling, it is resampling, using the algorithm it says.

Yes, now I see the problem more clearly!

One question: What is the rough conversion between buffer/period size and buffer/period time? mpd.conf will not use 1024/8192 in the 'time' domain and I found no alternative variable for buffer/period 'size'.

phofman · 2015-07-29 7:40 am

Very good.

This raised the CPU demand on the crossover to unacceptable levels. Lots of data underruns above 44.1kHz. ...so that was disappointing.

That was expectable. Resampling 4 channels with all the filters is way too much for the weak BBB.

One question: What is the rough conversion between buffer/period size and buffer/period time? mpd.conf will not use 1024/8192 in the 'time' domain and I found no alternative variable for buffer/period 'size'.

FramesPeriods - AlsaProject

Only the time representation is independent of samplerate, but will yield various buffer/period sizes for various samplerates.

First, I suggest to find safe parameters for non-resampling "plughw:0" chain (no ladspa filters involved for now, no "default" device). Please test aplay with 44100/4-channel wav, make 16bit as well as 32bit wav and try to find the -time combination which the soundcard accepts for all the required samplerates without resampling, for any of the bitwidth (as bitwidth/format can be specified in the plug plugin in the final asound.conf and will hold for all samplerates)

What is the soundcard driver? Is there a source code repository online? I would like to have a look why it switches the samplerates.

miero · 2015-07-29 9:26 am

I assume francolargo is using botic5 kernel, thus it mcasp driver from kernel 4.0 with these patches.

http://lxr.free-electrons.com/source/sound/soc/davinci/davinci-mcasp.c?v=4.0
https://github.com/miero/linux-dev/tree/master/patches/botic

The 44.1k, 48k, 88.2k and 96k should be working with 16/24/32 bits using 2 or 4 channels.

phofman · 2015-07-29 9:36 am

Well, then why does the soundcard refuse 44.100 and request 88.200? Is there some other way to force the card to some specific samplerate? E.g. there is lock_rate control in envy24 which forces the soundcard to stay at current fs.

I think we need to see the plain plughw:0 aplay debug output first.

miero · 2015-07-29 9:44 am

I have never tried plughw:0 neither mmap mode. Just plain hw:0 and executed with real-time priority using chrt.

In the current botic card driver there is no option to lock samplerate.

phofman · 2015-07-29 9:50 am

Can you test, please? aplay, 4 channels, 32bits as well as 16 bits, 44100. We need a single working set of buffer/period times for all samplerates. Then we can play with these to make the whole ladspa chain work.

Thanks.

miero · 2015-07-29 9:50 am

francolargo, please try following forcing of samplerate in your asound.conf or .asounrc

pcm.speaker {
type plug slave {
pcm "hw:0,0"
rate 44100
channels 4
}
}

phofman · 2015-07-29 9:59 am

miero said:
francolargo, please try following forcing of samplerate in your asound.conf or .asounrc

Ok, but in the end we need automatic samplerate selection as the chain must work for the whole range without resampling.

Honestly, I would prefer testing the plughw (of hw) chain with aplay first, there are too many other variables with the complicated ladspa chain involved.

francolargo · 2015-07-29 2:01 pm

Thanks gentlemen! I will have an interesting day of experimenting and report back this evening.

For future consideration, I wonder if source output to 'default' (rather than hw: or plughw: ) is contributing to the complexity. This source mentions that only the ...hw: inputs to alsa avoid initiating dmix. If true and dmix is forcing up sampling, another approach would be to create an alsa loopback as the pcm source for the filters. Then output could be specified as hw:1,0, and I just need to get the filters listening to hw:1,1.

Frank

phofman · 2015-07-29 2:41 pm

francolargo said:
For future consideration, I wonder if source output to 'default' (rather than hw: or plughw: ) is contributing to the complexity.

Your default device is a complex chain and of course it is adding useless complexity for now. That is why we should use only hw or plughw for now. plughw is just hw wrapped with the plug plugin (other notation is "plug:hw:0).

This source mentions that only the ...hw: inputs to alsa avoid initiating dmix. If true and dmix is forcing up sampling...

Dmix just like any other plugin must be specified in your chain to be active. It is specified in stock alsa definition of the "default" device, in /usr/share/alsa/... config files. You have your default overriden with your specific chain, there is no dmix involved. Alsa is really pretty transparent and does not do anything more you do not ask it.

It is resampling because the driver of your soundcard does not accept 44100 in combination with all the other params. We need to solve this issue (using just aplay with verbose plughw device).

miero · 2015-07-29 8:51 pm

I've just tested this. Using hw:0,0 works well, but using plughw:0,0 resamples 44k1 to 88k2. And I'm researching why it is done...

francolargo · 2015-07-29 9:42 pm

I can confirm this based on my search for working parameters using aplay. Using -D plughw:0, none of the period and buffer pairs I tried would play without up sampling. ...and I tried 10 pairs, four 4-track files each... Also, the lowest period/buffer size that played a 4ch, S32_LE, 96k file without under-runs was 256 - 2048. Using '-D default' always up samples. Meanwhile, SoX play always ran without resampling.

When I added 'rate 44100' to the last plug of asound.conf, the output was always 44.1k (with added CPU draw) , but when I added it to the first plug (before the filters) the filter output was up sampled.

Regarding temporary alternatives, I tried a few different default sample rate converters and only the linear interpolator would run on 4 channels above 44.1k.

Finally, I found that the default parameters for squeezelite are very poor choices for the BBB. Best CPU efficiency came from using [ -a 40:8::0 ] - and CPU load ~doubled by using mmap [i.e. -a 40:8::1]. Also good was [ -a 80:8::0 ].

During this testing I have been using my nice Sennheiser 'phones which run just fine from the bal/se converter of Buffalo 3 (in default asynch mode). Also I have been using the best-mastered files in my collection - very familiar sources. I am SO delighted with the non-resampled sound! I also have compared the RTlr4highpass LADSPA filter (with a low cutoff frequency) to unfiltered signal and don't notice any difference in critical areas like a) detail and saturation of strong transients, and b) fine resolution among voices in a chorus or instruments in a string section. So, I am totally convinced of the value in getting the unwanted up sampling resolved!

All the best,

Frank

miero · 2015-07-29 11:27 pm

Place following line into alsa.conf or .asoundrc for workaround that disables resampling:

pcm.plughw.slave.rate = "unchanged";

phofman · 2015-07-30 7:22 am

miero said:
I've just tested this. Using hw:0,0 works well, but using plughw:0,0 resamples 44k1 to 88k2. And I'm researching why it is done...

Very good. I think we should resolve this issue as it can be a potential hidden bug in the plug plugin or your driver. It certainly does not behave according to specs

If you could get libasound (and aplay at best) compiled with the debug symbols, debugging the device opening phase in gdb should be trivial since there are no multiple threads nor timing issues. We would see the negotation handshake betweeen the plug and hw plugins and could compare to the case without the plug involved.

francolargo · 2015-07-30 1:38 pm

Thanks miero - that does correct the situation when playing via plughw:. I wonder if a similar workaround could be effective playing via 'default', which still up samples. Any info or references much appreciated!

phofman · 2015-07-30 2:29 pm

I wonder if a similar workaround could be effective playing via 'default'

Of course, put it into configuration of the last plug plugin wrapping the hw section, i.e. into definition of your device "speaker".

francolargo · 2015-07-31 12:00 am

phofman said:
Of course, put it into configuration of the last plug plugin wrapping the hw section, i.e. into definition of your device "speaker".

Wonderful! Thanks for this suggestion - it led me to find the probable cause of the unwanted resampling! Satisfied that the rate problem was solved, I added a 'type-route' plug with a ttable. I wanted to simplify the needed channel swap between 1 and 2 using the ttable, so I then realigned the inputs and outputs in the LADSPA filter plugin. After that, rate "unchanged" was no longer needed downstream of the filter plugins! I left rate "unchanged" in the chain just in case somebody is tempted to mess with the input/output alignments of the ladspa plugins. Now it seems all the pieces of a decent two-way crossover are in place and working, and I'm very happy with the sound!

Next steps for me in the near term:
a) get some higher frequency source files and check CPU 'headroom' - is there enough CPU headroom for 196kHz, and/or to add a shelf or a notch filter in special cases? I am encouraged - we shall see!
b) use aplay and mpc to confirm the needed parameters for mpd.conf
c) confirm the best setup parameters for squeezelite ( -a XX:XX::0 )
d) report here with updated results, information, and new specific setup steps for others to try - and hopefully enjoy.

Longer term areas for more investigation:
a) The suite of filters from Richard Taylor doesn't include a specific band-pass for a three-way crossover. It would require a second instance of high and low-pass filters. The BBB/Cronus has enough channels (8) but does it have enough CPU for a three way crossover? (and what are the compromises?) I expect Charlie Laub's ACD modular filters to be somewhat more efficient and flexible than the RT filters. Charlie's ACD filter suite should be re-tested in the BBB.
b) Yes, DSD... All in good time...

LADSPA filters for digital crossovers on the BBB

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member