asoundrc and ladspa

[RAndyB]

Has anyone been able to prove that a LADSPA series such as that below actually does the processing in order, and not just the last one? After measuring and creating the Eq. I cannot persuade REW to play through the default, which includes the asoundrc Eq.

pcm.Eikona_Eq { type ladspa
                slave.pcm Monacor_Eq
                path "/usr/local/lib/ladspa"
                channels 4
                plugins {
#
# Eikona Eq 
#
# 
0 { label ACDf
    policy none
    input.bindings.0 "Input"
    output.bindings.0 "Output"
    input { controls [ 26 1 -10 90 20 1 1 ] } # PK gain Freq Q
  }
1 { label ACDf
    policy none
    input.bindings.0 "Input"
    output.bindings.0 "Output"
    input { controls [ 22 1 1 150 0.71 1 1 ] } # HP gain Freq Q
  }

 

[CharlieLaub]

Is this just a portion of your asoundrc file? It seems to be missing some "close curly braces"...

I think user fracolargo and jrubins have been using ACDf within ALSA successfully. Hopefully they will chime in here.

In this long tutorial, check out "Step 8a: Understanding the .asoundrc File"
Raspberry Pi Music Server With Built-in Crossover and DSP: 12 Steps (with Pictures)

 

[DonVK]

Great link, thanks Charlie.

 

[RAndyB]

Charlie,
only a portion, there are 8 eq. for the full range driver and 3 for the bass, and the crossovers.

The work of both francolargo and jrubins has informed this project. Perhaps you could give the parameters for an all-pass instance, in case I need it? I guessed at 7 zeroes, but I'm not sure that's right.

Thanks for the work you've put in.

Andy

 

[RAndyB]

...... so to prove it:

create a test track - see attachment
plus

0 { label ACDf; policy none;
    input.bindings.0 "Input"; output.bindings.0 "Output";
    input { controls [ 26 1 -40 100 10 1 1 ] } # notch 100
  }

and

0 { label ACDf; policy none;
    input.bindings.0 "Input"; output.bindings.0 "Output";
    input { controls [ 26 1 -40 3000 10 1 1 ] } # notch 3000
  }

Tested each one separately two hear two tones; added one into a slave of the other and heard one tone ; put them both into one LADSPA instance and heard one tone.

Conclusion is that ALSA code does what we all hope it will do -
Such excellent coding, pity about the User Manual.

 

[RAndyB]

The working equalisation (for the my non-existent audience) is attached.

The sound is excellent.

 

[DonVK]

Thanks for posting the solution. I'm trying to work my way through Linux Audio now. So seeing the attempts, debug, and solutions helps.

 

[RAndyB]

Oops!!!!

 

[RAndyB]

Another two problems solved

Problem the first:
Initially the Pi/ALSA had a very long latency, so was useless for TV sound. This was using:
arecord .... | aplay ..... (piping output to input).

Then I discovered alsaloop, and everything changed!

/home/rab/Public/Reset_paths.sh
/home/rab/Public/Record_from_SPDIF.sh
alsaloop -d -C plughw:CARD=RPiCirrus -P default -t 50000

The first two lines set the Cirrus Logic card, and the third line loops from the Cirrus Logic through alsa to output. The output "default" is the pcm of the asound.conf file shown earlier. A 50ms latency seems to cure problems of buffer underruns.

If anyone has experience of alsaloop and can shed light on the various options, I should be grateful.

Second problem:
Whenever the Pi is rebooted, something overwrites the .asoundrc in home directory.
A workaround - which will fail at a major software upgrade, probably - is to comment out the line in /usr/share/alsa/alsa.conf that includes the .asoundrc in home directory, and move the carefully crafted file to /etc/asound.conf.

Hope I am excused from bumping an elderly thread.

Andy