Important lesson learned about filter chains in ALSA:
Each instance of a filter has an input and output channel. It is the output channel in which the computational work is performed. IF you run more than one filter in a channel, it will distort - it will probably run but will not sound its best. In a 3-way crossover I had been running the high-pass and low-pass filters in the same channel. On very saturated passages of very high dB recordings I could hear clicks and 'scratchiness', though not at other times. When I changed the filter chain so that midrange high-pass happened in one channel and low pass in another, all was resolved. Much to my delight!
So for midrange, for example, for filter #1 input from 0 or 1 and output to 0 or 1, then for filter #2 input from 0 or 1 and output to 6 or 7.
Cheers,
Frank
Each instance of a filter has an input and output channel. It is the output channel in which the computational work is performed. IF you run more than one filter in a channel, it will distort - it will probably run but will not sound its best. In a 3-way crossover I had been running the high-pass and low-pass filters in the same channel. On very saturated passages of very high dB recordings I could hear clicks and 'scratchiness', though not at other times. When I changed the filter chain so that midrange high-pass happened in one channel and low pass in another, all was resolved. Much to my delight!
So for midrange, for example, for filter #1 input from 0 or 1 and output to 0 or 1, then for filter #2 input from 0 or 1 and output to 6 or 7.
Cheers,
Frank
There is another possibility, to use a virtual "Loopback" card (modprobe snd-aloop) and have a signal routed in following way:
- player outputs audio to the "hw:Loopback,0"
- ALSA routes internally the "hw:Loopback,0" to the "hw:Loopback,1"
- DSP (e.g. ecasound) processes the "hw:Loopback,1" to the "hw:Botic"
- player outputs audio to the "hw:Loopback,0"
- ALSA routes internally the "hw:Loopback,0" to the "hw:Loopback,1"
- DSP (e.g. ecasound) processes the "hw:Loopback,1" to the "hw:Botic"
I use an alsa loopback as part of my own DSP processing chains. What may not be obvious to some is that the loopback has a number of "substreams", and each of these can be used independently. So, if it helps, you can loop through the loopback multiple times, albeit with a small time delay penatly.
I believe you can choose how many substreams are available using the following syntax:
Code:
modprobe snd-aloop pcm_substreams=1Nice to have your input here, Charlie and Miero!
Certainly, the ALSA loopback has a lot of potential for various DSP tasks. I have played with it before for various ideas, none of which worked out. But now with 'recording' working in Botic there will probably be more possibilities. Before I got crossover filters running in ALSA I worked with Ecasound, which is certainly a good program. Of course, it has its own loop function outside of ALSA. However with Ecasound, I could never avoid it resampling to a single fixed and predetermined frequency. That's why I dug-in and started hacking with ALSA.
In ALSA, I'm only learning by making mistakes! I'm now testing cabinet performance for midrange drivers using Room EQ Wizard. What I am finding is that it is OK to reprocess the result from a primary LADSPA filter within any chosen ALSA channel - as long as the second filter on that same ALSA channel is in a separate plug. So I have an 8 channel plug for crossover duty that feeds an 8 channel plug for EQ and shelving adjustments. I have a difficult room... Who knows what the ALSA scheme for streams is! At some point I intend to learn how to directly adjust the ALSA buffer size, which IIRC is fixed at 4096...
In addition to checking filter performance with REW scans, I'm doing a good bit of critical listening. Things can sound good pretty good and the plots look good, and then you play some operatic aria and, whoa! - you probably killed the performance. So you compromise back to an uglier scan for better music! It leads me to the opinion that there are few better test samples than opera for knowing if emotion in music can be reproduced and if highly complex signals can be resolved. Of course, opera is an acquired taste - I grew up hearing it. I love all kinds of music but opera and tango hold a special place...
Now to take the midrange speakers apart and try a new cabinet modification...
Cheers!
Frank
Certainly, the ALSA loopback has a lot of potential for various DSP tasks. I have played with it before for various ideas, none of which worked out. But now with 'recording' working in Botic there will probably be more possibilities. Before I got crossover filters running in ALSA I worked with Ecasound, which is certainly a good program. Of course, it has its own loop function outside of ALSA. However with Ecasound, I could never avoid it resampling to a single fixed and predetermined frequency. That's why I dug-in and started hacking with ALSA.
In ALSA, I'm only learning by making mistakes! I'm now testing cabinet performance for midrange drivers using Room EQ Wizard. What I am finding is that it is OK to reprocess the result from a primary LADSPA filter within any chosen ALSA channel - as long as the second filter on that same ALSA channel is in a separate plug. So I have an 8 channel plug for crossover duty that feeds an 8 channel plug for EQ and shelving adjustments. I have a difficult room... Who knows what the ALSA scheme for streams is! At some point I intend to learn how to directly adjust the ALSA buffer size, which IIRC is fixed at 4096...
In addition to checking filter performance with REW scans, I'm doing a good bit of critical listening. Things can sound good pretty good and the plots look good, and then you play some operatic aria and, whoa! - you probably killed the performance. So you compromise back to an uglier scan for better music! It leads me to the opinion that there are few better test samples than opera for knowing if emotion in music can be reproduced and if highly complex signals can be resolved. Of course, opera is an acquired taste - I grew up hearing it. I love all kinds of music but opera and tango hold a special place...
Now to take the midrange speakers apart and try a new cabinet modification...
Cheers!
Frank
Greetings James,
I put that asound.conf file here for you to take a peek: https://github.com/francolargo/BBB-audio/blob/master/around.conf.6ch.4-29-16
This remains very much in flux. It seems the ear is a bit more discriminating than the Room EQ Wizard scans - what sounds like a fairly obvious change may barely show up on the scans. Perhaps I should pay more attention to the waterfall plots.
To tweak system response for the most satisfying presentation, I will probably have to use every trick available aside from moving furniture and hanging acoustic panels. It's the WAF thing (which is going well thus far). So in addition to adjustments in ALSA I'm also investigating what can be done with the es9018 chips' control registers via I2C. It's all easy enough to coordinate using my control setup. A few words on that here: http://www.diyaudio.com/forums/twis...bbb-based-audio-appliances-6.html#post4696574
So, having fun here learning what will work before I put the time into schmancy new driver cabinets...
Cheers,
Frank
I put that asound.conf file here for you to take a peek: https://github.com/francolargo/BBB-audio/blob/master/around.conf.6ch.4-29-16
This remains very much in flux. It seems the ear is a bit more discriminating than the Room EQ Wizard scans - what sounds like a fairly obvious change may barely show up on the scans. Perhaps I should pay more attention to the waterfall plots.
To tweak system response for the most satisfying presentation, I will probably have to use every trick available aside from moving furniture and hanging acoustic panels. It's the WAF thing (which is going well thus far). So in addition to adjustments in ALSA I'm also investigating what can be done with the es9018 chips' control registers via I2C. It's all easy enough to coordinate using my control setup. A few words on that here: http://www.diyaudio.com/forums/twis...bbb-based-audio-appliances-6.html#post4696574
So, having fun here learning what will work before I put the time into schmancy new driver cabinets...
Cheers,
Frank
James & friends,
I have continued to run experiments on the ALSA implementations of LADSPA crossover and EQ filters. I have a few more conclusions based on this new working model [ https://github.com/francolargo/BBB-audio/blob/master/asound.conf.6ch.5-3-16 ]:
1. I may have misinterpreted my data when I concluded that it is the output channel binding for each LADSPA filter that 'parses' the computational load. Because of today's experiments I'm not so sure. Certainly, with only the crossover filters running, it used to work to have both midrange high- and low-pass filters in the same ALSA plugin. Now, however, I have 6 EQ filters (times 2 channels) following the crossover filters per se. This broke something, and it was necessary to move one of the paired midrange filters out to a separate ALSA plugin to restore the basic crossover function.
2. Introducing: the 'identity' LADSPA filter (id # 1098)... this 'filter' does nothing except maintain a working channel thread through serial ALSA plugins that don't need to touch one or more of the (in this case 8) channels. Without it, that channel's content is lost in the final mix.
3. In ALSA there is very little headroom for an equalizer to bump up a signal. Some 'high dB' masters basically have zero headroom. Most have a few dB. I found that 3 dB was the most I could tweak a typically-quiet area, and 2 dB was usually OK at most frequencies. The distortion of clipping is easy to hear and unrelated to amp volume. Be nice to your drivers and test at low amp volume! I tried increasing the available headroom using the CMT LADSPA "amp" filter (# 1048), but sound quality took a heavy hit. There are other approaches to creating a bit of extra space, but trying them is not at the top of my list.
4. I am correcting for a really challenging room (with 6 meter-high ceiling) and am now up to a total of 10 filters each for the right and left sides. Predictably, computational cost has now limited the range of frequencies the BBB can source. With 96kHz material, TOP reports the CPU at 69%. Files at 192 and 176 kHz don't play. What I will do is set up a simpler signal path to use for higher frequencies and switch paths manually using the remote control. I'm OK with this because I have very little material higher than 96 kHz.
5. Regarding some of the specifics of the crossover filters (compared to previous setups): I'm liking the 2-pole crossover filter between woofers and mids because it is a bit more 'organic'. In the lower range, the mids can sound a bit sterile when using the 4-pole LR filter. To maintain phase alignment with the 2-pole filter, I merely cross the polarity of speaker wires between the woofer amp vs the midrange amp. Interestingly, even a 10 Hz difference in the XO point can affect the sound quality in the lower midrange. Also, with high frequency room modes, I chose to push the mid-tweeter XO point up to 5k. Even though the filter is 4-pole, the crossover zone got muddy down around 3k. ...much better clarity after moving up to 5k, and still far enough below the well-known 7k hump of the Lowther midranges.
Sound? Definitely smoothing out, and very few drawbacks from adding a bunch of "surgical" EQ dips to smooth out various sources of dissonance. Now the little es9018 adjustments that I can make on the fly are less important. Slow FIR rolloff sounds better all the time.
Cheers,
Frank
I have continued to run experiments on the ALSA implementations of LADSPA crossover and EQ filters. I have a few more conclusions based on this new working model [ https://github.com/francolargo/BBB-audio/blob/master/asound.conf.6ch.5-3-16 ]:
1. I may have misinterpreted my data when I concluded that it is the output channel binding for each LADSPA filter that 'parses' the computational load. Because of today's experiments I'm not so sure. Certainly, with only the crossover filters running, it used to work to have both midrange high- and low-pass filters in the same ALSA plugin. Now, however, I have 6 EQ filters (times 2 channels) following the crossover filters per se. This broke something, and it was necessary to move one of the paired midrange filters out to a separate ALSA plugin to restore the basic crossover function.
2. Introducing: the 'identity' LADSPA filter (id # 1098)... this 'filter' does nothing except maintain a working channel thread through serial ALSA plugins that don't need to touch one or more of the (in this case 8) channels. Without it, that channel's content is lost in the final mix.
3. In ALSA there is very little headroom for an equalizer to bump up a signal. Some 'high dB' masters basically have zero headroom. Most have a few dB. I found that 3 dB was the most I could tweak a typically-quiet area, and 2 dB was usually OK at most frequencies. The distortion of clipping is easy to hear and unrelated to amp volume. Be nice to your drivers and test at low amp volume! I tried increasing the available headroom using the CMT LADSPA "amp" filter (# 1048), but sound quality took a heavy hit. There are other approaches to creating a bit of extra space, but trying them is not at the top of my list.
4. I am correcting for a really challenging room (with 6 meter-high ceiling) and am now up to a total of 10 filters each for the right and left sides. Predictably, computational cost has now limited the range of frequencies the BBB can source. With 96kHz material, TOP reports the CPU at 69%. Files at 192 and 176 kHz don't play. What I will do is set up a simpler signal path to use for higher frequencies and switch paths manually using the remote control. I'm OK with this because I have very little material higher than 96 kHz.
5. Regarding some of the specifics of the crossover filters (compared to previous setups): I'm liking the 2-pole crossover filter between woofers and mids because it is a bit more 'organic'. In the lower range, the mids can sound a bit sterile when using the 4-pole LR filter. To maintain phase alignment with the 2-pole filter, I merely cross the polarity of speaker wires between the woofer amp vs the midrange amp. Interestingly, even a 10 Hz difference in the XO point can affect the sound quality in the lower midrange. Also, with high frequency room modes, I chose to push the mid-tweeter XO point up to 5k. Even though the filter is 4-pole, the crossover zone got muddy down around 3k. ...much better clarity after moving up to 5k, and still far enough below the well-known 7k hump of the Lowther midranges.
Sound? Definitely smoothing out, and very few drawbacks from adding a bunch of "surgical" EQ dips to smooth out various sources of dissonance. Now the little es9018 adjustments that I can make on the fly are less important. Slow FIR rolloff sounds better all the time.
Cheers,
Frank
Last edited:
Hi Frank,
looks like you in pretty deep here! Sounds an interesting project though!
I'm looking for help getting Squeezelite on BBB/Botic to run using an Alsa plug which splits the stereo PCM i2s data output into 2 separate channels of right justified data for use with my dual mono DDDAC dac.
I've been following the guide on the DDDAC thread here but I've got a bit lost at the final hurdle.
I've set it up as described and have the following ALSA thingy defined
and here's the output of my aplay -L
but if I change my squeezelite startup arguments from
squeezelite -o hw:CARD=Botic
to
squeezelite -o botic-split
I just get loud digital fuzz on the output of my dac whenever I hit play.
I would guess I'm missing something very simple, but I don't have the experience with this to spot what it is.
Any ideas/tips ?
thanks,
James
looks like you in pretty deep here! Sounds an interesting project though!
I'm looking for help getting Squeezelite on BBB/Botic to run using an Alsa plug which splits the stereo PCM i2s data output into 2 separate channels of right justified data for use with my dual mono DDDAC dac.
I've been following the guide on the DDDAC thread here but I've got a bit lost at the final hurdle.
I've set it up as described and have the following ALSA thingy defined
Code:
pcm.botic-split {
type route;
slave.pcm "hw:0,0";
slave.channels 4;
ttable.0.0 1;
ttable.0.1 1;
ttable.0.2 1;
ttable.1.3 1;
}
ctl.botic-split {
type hw;
card 0;
}and here's the output of my aplay -L
Code:
root@botic:~# aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
botic-split
default:CARD=Botic
Botic,
Default Audio Device
sysdefault:CARD=Botic
Botic,
Default Audio Device
dmix:CARD=Botic,DEV=0
Botic,
Direct sample mixing device
dsnoop:CARD=Botic,DEV=0
Botic,
Direct sample snooping device
hw:CARD=Botic,DEV=0
Botic,
Direct hardware device without any conversions
plughw:CARD=Botic,DEV=0
Botic,
Hardware device with all software conversionssqueezelite -o hw:CARD=Botic
to
squeezelite -o botic-split
I just get loud digital fuzz on the output of my dac whenever I hit play.
I would guess I'm missing something very simple, but I don't have the experience with this to spot what it is.
Any ideas/tips ?
thanks,
James
Hi James,
First, the reference with instructions you supplied is not using MPD.conf to send alsa output to program space, because it is sending the stream to hw:0,0. That I have done, and it is different from sending the stream to a default ALSA plugin for modification. We don't need to analyze that reference any further - I'm pretty sure we can handle what you need.
ALSA can be a real bear to debug because some syntaxes can break it without triggering error messages.
First, a reference on ALSA plugin structure and syntax:
ALSA project - the C library reference: Index Preamble and License
...and within this site:
ALSA project - the C library reference: PCM (digital audio) plugins
This site is the definitive guide to plugin structure and function.
OK, let's pull together some code that I know works with BBB/Botic.
First, let's declare a default plug and make it type-plug rather than type-route.
OK, now let's adapt a type-route plug that is working here and add it below those two cursory plugs:
I think this should work. Note that your t-table (as you aligned it) has three left channel outputs and one right channel output. Intentional?
Make an asound.conf file with these three plugs and then try 'aplay -L'. Obvious problems will be reported. If smooth sailing, then reboot and try sending a signal to the default output. I suggest 'speaker-test -c 2'. What happens?
First, the reference with instructions you supplied is not using MPD.conf to send alsa output to program space, because it is sending the stream to hw:0,0. That I have done, and it is different from sending the stream to a default ALSA plugin for modification. We don't need to analyze that reference any further - I'm pretty sure we can handle what you need.
ALSA can be a real bear to debug because some syntaxes can break it without triggering error messages.
First, a reference on ALSA plugin structure and syntax:
ALSA project - the C library reference: Index Preamble and License
...and within this site:
ALSA project - the C library reference: PCM (digital audio) plugins
This site is the definitive guide to plugin structure and function.
OK, let's pull together some code that I know works with BBB/Botic.
First, let's declare a default plug and make it type-plug rather than type-route.
Code:
pcm.!botic-split {
type plug
slave {
pcm "t-table"
rate "unchanged"
}
}
ctl.!default {
type hw
card 0
}OK, now let's adapt a type-route plug that is working here and add it below those two cursory plugs:
Code:
pcm.t-table {
type route
slave {
pcm "hw:0,0"
channels 4
}
ttable {
0.0 1 #left channel to output 0
0.1 1 #left channel to output 1
0.2 1 #left channel to output 2
1.3 1 #right channel to output 3
}
}I think this should work. Note that your t-table (as you aligned it) has three left channel outputs and one right channel output. Intentional?
Make an asound.conf file with these three plugs and then try 'aplay -L'. Obvious problems will be reported. If smooth sailing, then reboot and try sending a signal to the default output. I suggest 'speaker-test -c 2'. What happens?
Another word of explanation...
The exclamation point in the plug titles designates that plug as the default. Thus, if you execute 'squeezelite -l' you will see all of the available outputs to which squeezelite can supply a signal. -o default and -o botic-split are the same with the above asound.conf file.
The exclamation point in the plug titles designates that plug as the default. Thus, if you execute 'squeezelite -l' you will see all of the available outputs to which squeezelite can supply a signal. -o default and -o botic-split are the same with the above asound.conf file.
brilliant, thanks Frank
I'll give that a go later today.
For the tttable channels L&R, no that's not intentional and I don't see why it would be like that. Presumably that would mean that the first 2 channels were left, so even if I got this working, it would likely be in mono?
So I guess I actually want something more like this? to just give me 2 outputs, 1 each of left and right.
I'll give that a go later today.
For the tttable channels L&R, no that's not intentional and I don't see why it would be like that. Presumably that would mean that the first 2 channels were left, so even if I got this working, it would likely be in mono?
So I guess I actually want something more like this? to just give me 2 outputs, 1 each of left and right.
Code:
pcm.t-table {
type route
slave {
pcm "hw:0,0"
channels 4
}
ttable {
0.0 1 #left channel to output 0
1.1 1 #right channel to output 1
}
}In theory, you would expect that this would give true mono at each of the two L-R interleaved outputs:
However, when using Cronus outputs (not sure of exact names - in line with resistors) R5 & R4, I found the outputs were mixed and restoring mono via left-left and right-right alignment to the interleaved pairs would require:
If you're using different Cronus outputs, it is difficult to predict the system's behavior. Assuming there are no other glitches, just use 'speaker-test -c 2' to sort out the final destination of left-right signals for your DACs. Any other roadblocks - double-check that no 'odd characters' are in the ASCII and that there are no tabs, only spaces... ...all brackets closed, etc. Don't change the ttable from 4 to 2 outputs without also changing the above 'channels 4' to 'channels 2' - or possibly delete that line.
Code:
ttable {
0.0 1
1.0 1
2.1 1
3.1 1
}However, when using Cronus outputs (not sure of exact names - in line with resistors) R5 & R4, I found the outputs were mixed and restoring mono via left-left and right-right alignment to the interleaved pairs would require:
Code:
ttable {
0.0 1
1.1 1
2.0 1
3.1 1
}If you're using different Cronus outputs, it is difficult to predict the system's behavior. Assuming there are no other glitches, just use 'speaker-test -c 2' to sort out the final destination of left-right signals for your DACs. Any other roadblocks - double-check that no 'odd characters' are in the ASCII and that there are no tabs, only spaces... ...all brackets closed, etc. Don't change the ttable from 4 to 2 outputs without also changing the above 'channels 4' to 'channels 2' - or possibly delete that line.
Last edited:
ok, now I get
and
I can run
and it seems to run through, but i get no sound at my speakers
and I can start squeezelite using the botic-split output and as before i get a swishing white noise whenever I press play. It kind of seems as though maybe the software is ok and I have my wiring wrong. I'll check that out.
Code:
aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
botic-split
t-table
default:CARD=Botic
Botic,
Default Audio Device
sysdefault:CARD=Botic
Botic,
Default Audio Device
dmix:CARD=Botic,DEV=0
Botic,
Direct sample mixing device
dsnoop:CARD=Botic,DEV=0
Botic,
Direct sample snooping device
hw:CARD=Botic,DEV=0
Botic,
Direct hardware device without any conversions
plughw:CARD=Botic,DEV=0
Botic,
Hardware device with all software conversionsand
Code:
root@botic:~# squeezelite -l
Output devices:
null - Discard all samples (playback) or generate zero samples (capture)
botic-split
t-table
default:CARD=Botic - Botic, - Default Audio Device
sysdefault:CARD=Botic - Botic, - Default Audio Device
dmix:CARD=Botic,DEV=0 - Botic, - Direct sample mixing device
dsnoop:CARD=Botic,DEV=0 - Botic, - Direct sample snooping device
hw:CARD=Botic,DEV=0 - Botic, - Direct hardware device without any conversions
plughw:CARD=Botic,DEV=0 - Botic, - Hardware device with all software conversionsI can run
Code:
root@botic:~# speaker-test -D botic-split -c 2and I can start squeezelite using the botic-split output and as before i get a swishing white noise whenever I press play. It kind of seems as though maybe the software is ok and I have my wiring wrong. I'll check that out.
To be sure I understand:
With 'speaker-test -c 2 -D default' do you get sound (white noise)? How about 'speaker-test -c 2 -D hw:0,0' (any kind of white noise...)?
Also, which version of squeezelite? ('squeezelite -?')
Do you get the noise when you execute 'squeezelite -o hw:0,0'? (keep volumes low)
It seems like ALSA is not working, but we had best be sure your software can put sound out through 'hw:0,0', which bypasses the ALSA plugins.
If hw:0,0 gives some sound, then please post your /etc/asound.conf file.
...and did you type it anew, or copy/paste?
[This is why we're not over on the Botic support thread! ]
With 'speaker-test -c 2 -D default' do you get sound (white noise)? How about 'speaker-test -c 2 -D hw:0,0' (any kind of white noise...)?
Also, which version of squeezelite? ('squeezelite -?')
Do you get the noise when you execute 'squeezelite -o hw:0,0'? (keep volumes low)
It seems like ALSA is not working, but we had best be sure your software can put sound out through 'hw:0,0', which bypasses the ALSA plugins.
If hw:0,0 gives some sound, then please post your /etc/asound.conf file.
...and did you type it anew, or copy/paste?
[This is why we're not over on the Botic support thread!
]
oh gosh! I think I have it sorted!
I've checked and re-checked, even dug my scope out and been playing test tones and poking about like this
And everything looked fine and I was baffled and going back and forth, but as part of this testing I have made music appear!
For some reason I don't understand, if I turn the volume down within Squeezelite to below about 12/100 then I get distortion-free music. Much above that and it's hugely overdriven with distortion and over about 25/100 all I get is swishy digital white noise.
Do you have any idea why that might be so?
Regardless, I can move this off my test bench and enjoy some well earned tunes for now
thanks,
James
I've checked and re-checked, even dug my scope out and been playing test tones and poking about like this
An externally hosted image should be here but it was not working when we last tested it.
And everything looked fine and I was baffled and going back and forth, but as part of this testing I have made music appear!
For some reason I don't understand, if I turn the volume down within Squeezelite to below about 12/100 then I get distortion-free music. Much above that and it's hugely overdriven with distortion and over about 25/100 all I get is swishy digital white noise.
Do you have any idea why that might be so?
Regardless, I can move this off my test bench and enjoy some well earned tunes for now
thanks,
James
Sorry, I'm not much help there. At least ALSA is not the primary issue! I'm not sure how you will determine a 'zero-point', at which the signal is theoretically unattenuated. Perhaps take this up with the DDDAC folks. I will add that with my Cronus ->B3 setup, some very 'loud' masters will cause 'minor' digital clipping, which sounds like 'scratchiness' in the transients. This can be removed by lowering volume in Squeezelite. However, 99% of my volume control is done via I2C to each of the B3s. Of the two methods, attenuation by the DAC is noticeably cleaner.
Cheers!
Frank
Cheers!
Frank
oh gosh! I think I have it sorted!
I've checked and re-checked, even dug my scope out and been playing test tones and poking about like this
And everything looked fine and I was baffled and going back and forth, but as part of this testing I have made music appear!
For some reason I don't understand, if I turn the volume down within Squeezelite to below about 12/100 then I get distortion-free music. Much above that and it's hugely overdriven with distortion and over about 25/100 all I get is swishy digital white noise.
Do you have any idea why that might be so?
Regardless, I can move this off my test bench and enjoy some well earned tunes for now
thanks,
James
You're probably increasing the signal over 0db somewhere or another. Check alsamixer, set your level to 90. Make sure your total level boost doesn't go above 0.
Also, make sure your squeezelite is running as the same user as your asound.conf user. If you get different sound results when running speaker-test and sudo speaker test, that could be the case.
Wow, the ACDf suite of filters sounds terrific! Clearly superior resolution compared to the RT filters that I have been using in Debian Wheezy 7.5. Unfortunately, Debian Jessie 8.4 (needed for ACDf) seems to have a fault whereby USB 2.0 inputs can be listed, but not addressed. More research needed, but it seems serious. Will try previous versions of both - Botic5 for the kernel and Jessie 8.3 for the OS.
Any insights much appreciated!
Frank
Any insights much appreciated!
Frank
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.