Go Back   Home > Forums > >
Home Forums Rules Articles diyAudio Store Blogs Gallery Wiki Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

PC Based Computer music servers, crossovers, and equalization

Raspberry Pi with Piano2.1 DAC DSP and Volumio2
Raspberry Pi with Piano2.1 DAC DSP and Volumio2
Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 3rd March 2019, 04:15 AM   #141
soundnovice is offline soundnovice
diyAudio Member
 
Join Date: Jan 2011
i need 1.5ms of delay that includes the delay mentioned for harsch xover + driver alignment
  Reply With Quote
Old 3rd March 2019, 05:47 AM   #142
DonVK is offline DonVK  Canada
diyAudio Member
 
DonVK's Avatar
 
Join Date: Jan 2017
Location: Ottawa
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.

Last edited by DonVK; 3rd March 2019 at 05:52 AM. Reason: typo
  Reply With Quote
Old 5th March 2019, 02:47 PM   #143
DonVK is offline DonVK  Canada
diyAudio Member
 
DonVK's Avatar
 
Join Date: Jan 2017
Location: Ottawa
Default 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.
Attached Images
File Type: jpg DSCN3226 crop_text.jpg (203.0 KB, 290 views)
File Type: jpg Harsch delay and filter table.jpg (157.1 KB, 293 views)
File Type: jpg Harsch DAC0 left schematic.jpg (312.4 KB, 284 views)
File Type: jpg Harsch DAC1 right schematic.jpg (311.1 KB, 277 views)
Attached Files
File Type: zip 2.2-9.zip (179.9 KB, 2 views)
File Type: zip ReadMe + Project.zip (284.8 KB, 4 views)
  Reply With Quote
Old 5th March 2019, 07:31 PM   #144
ngfy is offline ngfy  Poland
diyAudio Member
 
Join Date: Feb 2019
Location: Wroclaw
It sounds really interesting. Would it be possible to create a firmawe with passtrought instead of LP (the rest unchanged)?
  Reply With Quote
Old 7th March 2019, 04:40 AM   #145
DonVK is offline DonVK  Canada
diyAudio Member
 
DonVK's Avatar
 
Join Date: Jan 2017
Location: Ottawa
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.
  Reply With Quote
Old 19th November 2019, 09:09 PM   #146
mfeif is offline mfeif
diyAudio Member
 
Join Date: Mar 2016
Default 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:

Code:
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!
  Reply With Quote
Old 22nd November 2019, 03:20 AM   #147
DonVK is offline DonVK  Canada
diyAudio Member
 
DonVK's Avatar
 
Join Date: Jan 2017
Location: Ottawa
Quote:
Originally Posted by mfeif View Post

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.

Quote:
Originally Posted by mfeif View Post
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.


Quote:
Originally Posted by mfeif View Post
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.

Quote:
Originally Posted by mfeif View Post
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.

Quote:
Originally Posted by mfeif View Post
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.


Quote:
Originally Posted by mfeif View Post
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

Quote:
Originally Posted by mfeif View Post
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.
  Reply With Quote
Old 22nd November 2019, 08:57 PM   #148
mfeif is offline mfeif
diyAudio Member
 
Join Date: Mar 2016
Quote:
Originally Posted by DonVK View Post
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!


Quote:
Originally Posted by DonVK View Post
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?



Quote:
Originally Posted by DonVK View Post
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.



Quote:
Originally Posted by DonVK View Post
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:


Code:
[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.


Quote:
Originally Posted by DonVK View Post
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!
  Reply With Quote
Old 23rd November 2019, 02:20 AM   #149
DonVK is offline DonVK  Canada
diyAudio Member
 
DonVK's Avatar
 
Join Date: Jan 2017
Location: Ottawa
Quote:
Originally Posted by mfeif View Post
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.


Quote:
Originally Posted by mfeif View Post
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
  Reply With Quote
Old 23rd November 2019, 03:28 AM   #150
mfeif is offline mfeif
diyAudio Member
 
Join Date: Mar 2016
Good point; I will have to wait and measure the actual real world thing once I've built it :-)
  Reply With Quote

Reply


Raspberry Pi with Piano2.1 DAC DSP and Volumio2Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
DAC for Raspberry Pi LaxAnErde Digital Line Level 40 15th May 2019 04:00 AM
Raspberry Pi DAC Help! pamantea Digital Source 31 19th April 2019 11:24 PM
Tutorial: Raspberry Pi as Music Server, DSP, and Crossover jrubins PC Based 75 6th January 2017 05:28 AM
DSP for the Raspberry Pi usul27 Digital Line Level 39 30th August 2016 08:29 AM
Which DAC for Raspberry Pi? Miller-8 PC Based 14 10th August 2016 04:18 AM


New To Site? Need Help?

All times are GMT. The time now is 12:10 PM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 14.29%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
Copyright ©1999-2019 diyAudio
Wiki