Raspberry Pi with Piano2.1 DAC DSP and Volumio2

[soundnovice]

i need 1.5ms of delay that includes the delay mentioned for harsch xover + driver alignment

 

[DonVK]

I've never tried a Harsch, so that's a LP-BW4, with HP-BSL2, and delay the HP filter by 1/2 of the fc period (1 / 2*fc). In your case the XO is 300Hz-ish and delay @48K sampling is 72 samples. That should be possible.

The delay #samples would vary with both fc and sampling rate. A complete filter data set (all XO points at all sample rates) may not be possible because the #samples would get large when the sample rate increases and fc decreases. I'll have a look to see whats possible.

 

[DonVK]

Piano Firmware 2.2-9 -> Harsch XO for FAST/WAW

I implemented a Harsch filter for a 2 way, with XO points typically used in FAST / WAW systems (eg. woofer + fullrange)

The LP-BW4 and HP-BSL2 are straight forward to implement and TI_PP supports "configurations" to automatically generate the coefficients for all the required sample rates. The DAC DSP also has local memory that can be used for implementing a delay line. The delay block can store 600 samples (@32bit) using this memory. That's enough to create the delays required for this Harsch implementation down to XO@200Hz with sample rate 192Khz. So a full filter data set, for all XO and sample freq, is possible. One issue is the way TI_PP treats the delay as "constant value" for all configurations and it's value can only be changed in the "main" configuration. So if you want exact delays for every configuration (XO+sample freq) you would need to recompile for each delay value change (via main).

The table below lists the delays (in #samples) that are required for each sample freq and XO freq. I generated exact delay configurations (qty 15) for only the 48KHz sample rate set. The other sample rates have reused these 15 delay values to complete the data set and save me time . The table cell color indicates which delay value (see 48Khz column) were used, and the number in the cell indicates the exact value required. The project files are included if you want to regenerate them exactly for all sample freq or if you need to add a delay for your driver position offsets. If you just want to try it, the 48K sample rate has the most accurate implementation. I've done some limited testing with it.

 

[ngfy]

It sounds really interesting. Would it be possible to create a firmawe with passtrought instead of LP (the rest unchanged)?

 

[DonVK]

Maybe if I can find a way to parameterize the delay in a configuration so it changes automatically with sample rate. Right now its a manual (time consuming) process.

 

[mfeif]

So great to re-read all this

Thanks to Don and all of you; I posted a while back asking about using this to make the Linkwitz LX-Mini project.

I've been enjoying my Sparky > Piano 2.1 > Kali setup to just a small amp and some speakers, but I'm gearing up to build the LX minis this winter.

I've got my PurePath license and software installed on a VM, and I'm trying to get up to speed enough with all of this stuff to not get terribly frustrated. I may come here for questions about the analog/DSP side of things, as I am super ignorant there. There are lots of people in the Linkwitz forums who are kinda scolding (or I should say warning) folks about trying to replicate the transforms in the MiniDSP product on other platforms... they write that the terminology and measurements vary and it's not easy to replicate without measurement and testing. And I don't have tools or expertise to do those measurements...

So first question, maybe DonVK, from what you've seen in PurePath (and I saw that you thought it was an excellent environment) is it likely that it's pretty close to how the MiniDSP software computes EQ and delay and so forth? I know, no guarantees and all of that.

I can maybe share something back... I'm not using Volumio (I'm using DietPi, which a couple years ago seemed to more well support the Sparky, a rPi-like board from Allo). SO, I can't use the Volumio UI to set different firmwares. But I suspected that Volumio wasn't poking at the kernel directly, and thought there must be something simpler going on. And there is:

The different profiles are set by standard alsa command line tools; you can look at them with alsamixer. DietPi uses their own tool called "dietpi-justboom" which just uses a console menu system to configure command line stuff. Here's an example of some of those lines:

local dsp_filter=$(amixer -c $SOUNDCARD_CARD_INDEX sget "'DSP Program'" | grep 'Item0:' | sed 's/.*Item0: //')
G_WHIP_MENU_ARRAY+=("DSP Filter" ": $dsp_filter")
local digital_volume_int=$(amixer -c $SOUNDCARD_CARD_INDEX sget "'Digital'" | grep 'Front Left:' | mawk '{print $4}')
local digital_volume_db=$(amixer -c $SOUNDCARD_CARD_INDEX sget "'Digital'" | grep 'Front Left:' | mawk '{print $6}' | tr -d '\[\]')
local subwoofer_mode=$(amixer -c $SOUNDCARD_CARD_INDEX sget "'Subwoofer mode'" | grep 'Item0:' | sed 's/.*Item0: //')
local subwoofer_volume_int=$(amixer -c $SOUNDCARD_CARD_INDEX sget "'Subwoofer'" | grep 'Front Left:' | mawk '{print $4}')
local subwoofer_volume_db=$(amixer -c $SOUNDCARD_CARD_INDEX sget "'Subwoofer'" | grep 'Front Left:' | mawk '{print $6}' | tr -d '\[\]')
local subwoofer_crossover_frequency=$(amixer -c $SOUNDCARD_CARD_INDEX sget "'Lowpass'" | grep 'Item0:' | sed 's/.*Item0: //')
local dualoutput_mode=$(amixer -c $SOUNDCARD_CARD_INDEX sget "'Dual Mode'" | grep 'Item0:' | sed 's/.*Item0: //')

So they're using the 'amixer' utility to poke at the sound driver. So we can influence this card and the firmware settings without Volumio if we want to, just by using the right combination of alsamixer (for interactive setting) and with amixer for scripted use. One can also use "alsactl" to save and load whole batches of settings and apply they en-masse. This might be a good way to go. I use this feature to "backup" the settings of the driver once I get it working, because it seems really easy to flip the wrong switch and have something silent or weird.

Which brings me to the sound driver itself. I found the source code here: Linux/allo-piano-dac-plus.c at master * sparkysbc/Linux * GitHub

Unfortunately, you can see that the firmware stuff is hard-coded, so the "hack" that we can use to put in custom DSP features has to stay this way. I expect that a competent C programmer could make a variation on this code to make a module that looks in another place/way to find firmwares, but that's beyond me

Don, are you replacing ALL of the crossover points with the DSPs that you want, or just remembering to keep it locked in at the one(s) that you've modified?

Thanks everyone! If anyone has already made LXMinis, please let us all know!

 

[DonVK]

I've got my PurePath license and software installed on a VM, and I'm trying to get up to speed enough with all of this stuff to not get terribly frustrated.

Congrats @mfeif good to see you back. Sorry for the response delay. If you have questions about the s/w just ask. There may be some answers in this thread already.

they write that the terminology and measurements vary and it's not easy to replicate without measurement and testing. And I don't have tools or expertise to do those measurements...

It's alot easier and more consistent if you have a microphone and something like REW to do measurements. Then base your adjustments on measurements because your drivers and construction are probably a little different.

So first question, maybe DonVK, from what you've seen in PurePath (and I saw that you thought it was an excellent environment) is it likely that it's pretty close to how the MiniDSP software computes EQ and delay and so forth? I know, no guarantees and all of that.

I think that can be easily done. DSP is DSP and it does not matter what CPU/GPU/DSP actually does it. You can implement analog equivalents easily as well.

I can maybe share something back... I'm not using Volumio (I'm using DietPi, which a couple years ago seemed to more well support the Sparky, a rPi-like board from Allo). SO, I can't use the Volumio UI to set different firmwares. But I suspected that Volumio wasn't poking at the kernel directly, and thought there must be something simpler going on. And there is:

Thanks, I'll need to look into this. I thought there was a hardware overlay for the Piano at startup and it was used to load the firmware.

So they're using the 'amixer' utility to poke at the sound driver. So we can influence this card and the firmware settings without Volumio if we want to, just by using the right combination of alsamixer (for interactive setting) and with amixer for scripted use. One can also use "alsactl" to save and load whole batches of settings and apply they en-masse. This might be a good way to go. I use this feature to "backup" the settings of the driver once I get it working, because it seems really easy to flip the wrong switch and have something silent or weird.

Again, I would need to look at this. It does not seems intuitive to allow alsactl or alsamixer to load the firmware. There are switches in alsamixer to select DSP filters and modes but only after the DSP firmware is loaded.

Which brings me to the sound driver itself. I found the source code here: Linux/allo-piano-dac-plus.c at master * sparkysbc/Linux * GitHub

Unfortunately, you can see that the firmware stuff is hard-coded, so the "hack" that we can use to put in custom DSP features has to stay this way. I expect that a competent C programmer could make a variation on this code to make a module that looks in another place/way to find firmwares, but that's beyond me

That I was aware of, which is why I "reuse" the DSP filenames. I'm not skilled enough to make the code changes required to load generic filenames

Don, are you replacing ALL of the crossover points with the DSPs that you want, or just remembering to keep it locked in at the one(s) that you've modified?

Purepath can automatically generate a DSP "set" for all sample freq. So the firmware I've listed will support all sample freq for all the new XO points listed. They are complete sets.

 

[mfeif]

Congrats @mfeif good to see you back. Sorry for the response delay. If you have questions about the s/w just ask. There may be some answers in this thread already.

Thanks!

It's alot easier and more consistent if you have a microphone and something like REW to do measurements. Then base your adjustments on measurements because your drivers and construction are probably a little different.

I'm sticking to the plans, drivers, everything, save one thing: using the Piano 2.2 instead of the MiniDSP; I was hoping I could measure the output of the Piano line outs itself (probably just by plugging them into a line-in on my laptop) and graph the response and compare to the standard from MiniDSP and Linkwitz' design. Does that make sense?

I think that can be easily done. DSP is DSP and it does not matter what CPU/GPU/DSP actually does it. You can implement analog equivalents easily as well.

Yeah, that's what I hoped. I see people talking about different "Q values" and stuff. Not sure what that means yet, but I presume it's parameters to the different kinds of things one can add into the signal path.

Thanks, I'll need to look into this. I thought there was a hardware overlay for the Piano at startup and it was used to load the firmware.

You can confirm this yourself by going into alsamixer and changing (for example) the crossover frequency, then looking in the dmesg log for the kernel:

[323457.035378] pcm512x 2-004c: Dsp Firmware File Name: allo/piano/2.2/allo-piano-dsp-44100-70-0.bin
[323457.674601] pcm512x 2-004c: Dsp Firmware File Name: allo/piano/2.2/allo-piano-dsp-44100-70-1.bin

Regarding your comment about intuitive, I agree. I believe that what happens is that the driver is configured to an initial state, which is probably living in /var/lib/alsa/asound.state... this would be used upon boot on a "normal" linux system. It will likely pull the last known state before reboot from there, and if that file is missing, would start from some kind of sane default.


There are no messages like that produced if you select a 2.0 mode, so likely the driver only loads that stuff if we choose 2.2 or 2.1.


I think that the "overlay" thing is a hack that we use to pass stuff to a kernel on a rPi like system; this way we can edit a text file on an SD card in Windows (or what have you) rather than having to work with a CLI on a running linux box. I'm comfortable with the latter, so I'd prefer to have that rather than some of the "hacks" but I think they're getting the same result.

DietPi has something similar yet different, with a txt file living on the card. I haven't yet figured out where/how DietPi sets soundcard configs so they will survive a reboot; not sure about Volumio either. I'll have to try Volumio.

Purepath can automatically generate a DSP "set" for all sample freq. So the firmware I've listed will support all sample freq for all the new XO points listed. They are complete sets.

Yeah! I read something about that in your previous posts. I don't understand how yet, but I hope to be able to deduce it from your posts and your example files.




Here's a question: I'm wondering how to split up the work among the two DSP chips; should I have one chip do both low-pass configurations and one do high-pass, or have one to left and one right? I know that there is a small delay set in the high-pass, if that matters. I might be over-thinking this!


Thanks!

 

[DonVK]

Thanks!

I'm sticking to the plans, drivers, everything, save one thing: using the Piano 2.2 instead of the MiniDSP; I was hoping I could measure the output of the Piano line outs itself (probably just by plugging them into a line-in on my laptop) and graph the response and compare to the standard from MiniDSP and Linkwitz' design. Does that make sense?

The problem is you still won't know how the entire speaker is performing and whether any additional EQ is required unless you measure with a mic.

You could also use Ecasound or Brutefir if you need additional speaker EQ or room EQ.

Here's a question: I'm wondering how to split up the work among the two DSP chips; should I have one chip do both low-pass configurations and one do high-pass, or have one to left and one right? I know that there is a small delay set in the high-pass, if that matters. I might be over-thinking this!

Thanks!

I've done both ways. I "believe" that the DACs are run synchronously so they should update all outputs at the same time. However I have never measured the phase between DAC outputs because it never caused me any problems. Maybe I should

 

[mfeif]

Good point; I will have to wait and measure the actual real world thing once I've built it

 

[mfeif]

A few questions...

I've been working through reproducing MiniDSP Linkwitz configs. I've found a few questions, wondering if you might have any insight:

1. Did you see a way to simply lower over-all gain by a certain db?

2. Is there a way to invert polarity of the signal?

3. I saw your writing above about delay; I see that (so far) you had determined that there was no way to delay by time and have the software figure out the samples. So, given that, how would someone generate different "sets" for different sample rates? When configuring a delay setting (as per your 2.2.9) I don't see how to specify which sample rate that block applies to, and when I've tried to "Generate" it just goes to town.

4. Any notion about the difference between the different kinds of biquad blocks? ROM, Multi, etc?


Thanks so much -- in advance.




Thanks!

 

[mfeif]

Making progress!

I've been able to make these configs; I elected to have one DAC do the "woofers" and one the "full range". Would you be willing to give them a peek?

I found a way to delay by just a few samples (which is all I need). I read some more of the manuals for PurePath, and to answer my own question, I don't think it's going to be possible to parameter-ize the delay settings. I'll just have to cut files manually and adjust.

Regarding volume, I found a block that does that, unfortunately it won't meet the granularity I need: I need -9.8dB applied to the whole signal path but it can only do whole numbers. Oh well, 0.2dB is pretty close.

Some questions, if I may:

1. Would the "Negate" block be the same as acoustic polarity switch? I don't know if the bytes coming through the DSP are signed, or not. (These files do "work" on my actual machine, but of course I can't hear polarity or phase.)

2. When working with the BiQuad block, do you know why/when the "scale" column kicks in? It seems to be setting those values automatically, and it's changing the parameters I aim to set. For example, that #2 in this screenshot doesn't seem to give me the full 8db because of that scale... so I can't set up what I'm trying to do, unless I don't understand how it works (which is likely).

Thanks! Your java program is working nicely to convert; the instructions that I have from Allo on doing it with the command line aren't working for me, so it was great to have this. Thank your son for me!

 

[Davey]

The problem is you still won't know how the entire speaker is performing and whether any additional EQ is required unless you measure with a mic.
)

The initial objective is (should be) to match the electrical curves of the design by Siegfried. THAT is what guarantees the entire speaker is performing correctly.

Once that's accomplished, then it's completely up to the user if/how to proceed further. That might involve acoustic measurements, or it might not.

Dave.

 

[mfeif]

Yep, I agree. I'm working up to that in steps.

 

[Davey]

Yep, I agree. I'm working up to that in steps.

As a first step, you might also consider a much simplified transfer function scheme that doesn't have the myriad dips/wiggles/etc that SL designed into the original system. You can alter the EQ settings and crossover points to achieve something fairly similar to the original curves. That approach is the essence of the LXmini ASP designed by Nelson Pass. Try using that as your matching objective and you will be right in the ball park.

In addition, I suspect you will run out of processing power trying to achieve the designed transfer curves using the PCM5142 capability. (I'm not aware of anybody who's successfully done that.)

Dave.

 

[mfeif]

As a first step, you might also consider a much simplified transfer function scheme that doesn't have the myriad dips/wiggles/etc that SL designed into the original system. You can alter the EQ settings and crossover points to achieve something fairly similar to the original curves. That approach is the essence of the LXmini ASP designed by Nelson Pass. Try using that as your matching objective and you will be right in the ball park.

In addition, I suspect you will run out of processing power trying to achieve the designed transfer curves using the PCM5142 capability. (I'm not aware of anybody who's successfully done that.)

Dave.

All the curves did cook into .cfg files just fine; I think they're "wrong" because the PurePath software is trying to help me avoid clipping by scaling EQ items that boost a signal... so while all the curves do process, I'm pretty sure they're wrong. That's kindof a kick in the teeth. So, yeah, copying settings over from another product/metaphor seems to be a wild goose chase.


So, to measuring. I'm hoping I can measure without mastering ARTA . Do I just generate pink noise on the pi and then measure with a PC?


Thanks for all the help. I was hoping to get this "right" so I could share it with others who wanted to take a crack at this. Seems like it's not going to be solid enough to recommend to others.

 

[DonVK]

I've been able to make these configs; I elected to have one DAC do the "woofers" and one the "full range". Would you be willing to give them a peek?

I found a way to delay by just a few samples (which is all I need). I read some more of the manuals for PurePath, and to answer my own question, I don't think it's going to be possible to parameter-ize the delay settings. I'll just have to cut files manually and adjust.

No problem to review the code. I compiled it and is seems OK. Are you replicating the digital or analog (Pass simplified) version of the XO?

A full DSP set has "m x n" configs (m=#XO points, n=#sample freq). So if your XO point is fixed, you could generate differents delays and associate them with each XO selection.

Regarding volume, I found a block that does that, unfortunately it won't meet the granularity I need: I need -9.8dB applied to the whole signal path but it can only do whole numbers. Oh well, 0.2dB is pretty close.

I think that would be precise enough.

Some questions, if I may:

1. Would the "Negate" block be the same as acoustic polarity switch? I don't know if the bytes coming through the DSP are signed, or not. (These files do "work" on my actual machine, but of course I can't hear polarity or phase.)

Yes that inversion will create acoustic inversion, but if the polarity is inverted "incorrectly" w.r.t. other driver you will create a deep acoustic null and you will hear it.

2. When working with the BiQuad block, do you know why/when the "scale" column kicks in? It seems to be setting those values automatically, and it's changing the parameters I aim to set. For example, that #2 in this screenshot doesn't seem to give me the full 8db because of that scale... so I can't set up what I'm trying to do, unless I don't understand how it works (which is likely).

The scaling is actually gain applied to the BiQuad. If you view it in the frequency tab you can see the vertical gain shift. You can only scale down in a BiQuad. The EQ blocks are set automatically based on the Q.

Thanks! Your java program is working nicely to convert; the instructions that I have from Allo on doing it with the command line aren't working for me, so it was great to have this. Thank your son for me!

I'll forward the thanks, he'll appreciate it.

 

[DonVK]

The initial objective is (should be) to match the electrical curves of the design by Siegfried. THAT is what guarantees the entire speaker is performing correctly.

Once that's accomplished, then it's completely up to the user if/how to proceed further. That might involve acoustic measurements, or it might not.

Dave.

Those curves are for a specific set of drivers and construction. If you swap drivers there is no assurance you'll get the same performance without changing the EQ.

 

[DonVK]

As a first step, you might also consider a much simplified transfer function scheme that doesn't have the myriad dips/wiggles/etc that SL designed into the original system. You can alter the EQ settings and crossover points to achieve something fairly similar to the original curves. That approach is the essence of the LXmini ASP designed by Nelson Pass. Try using that as your matching objective and you will be right in the ball park.

In addition, I suspect you will run out of processing power trying to achieve the designed transfer curves using the PCM5142 capability. (I'm not aware of anybody who's successfully done that.)

Dave.

Right now, based on the files provided, he's at 33% resources on the woofer DAC and 50% resources on the full range DAC.

 

[DonVK]

All the curves did cook into .cfg files just fine; I think they're "wrong" because the PurePath software is trying to help me avoid clipping by scaling EQ items that boost a signal... so while all the curves do process, I'm pretty sure they're wrong. That's kindof a kick in the teeth. So, yeah, copying settings over from another product/metaphor seems to be a wild goose chase.


So, to measuring. I'm hoping I can measure without mastering ARTA . Do I just generate pink noise on the pi and then measure with a PC?


Thanks for all the help. I was hoping to get this "right" so I could share it with others who wanted to take a crack at this. Seems like it's not going to be solid enough to recommend to others.

I don't understand. Is this from measuring the response of the DACs? Where is the scaling problem ?