Raspberry Pi with Piano2.1 DAC DSP and Volumio2

I spent a bit more time to actually finesse the filters this time.

The subwoofer channels (DAC#1) use a mixed RL low passed at 80Hz (BW4) and sent to both outputs. The difference this time is the use of extended precision in the coeffs. One of the problems with setting low cutoff frequencies in a digital IIR (biquad) is that the coefficients get close to unity (ie. 0.99999965) and preserving significance is a problem.

The stereo channel (DAC#0) is high passed at 80Hz (BW4) and has additional speaker EQ. The EQ curve was initially generated earlier by REW and then manually repeated here using 6 biquads. The speakers have an internal passive LR4 but the driver responses are not FR flat. This EQ curve helps that. The DSP load is at 42% utilization now.

Overall it sounds good. This means I can do active XO and speaker EQ in the DAC's DSP.

Do you mind elaborating on what you are doing with the coefficient filter? I can copy your diagram but what are you setting it to? It looks like the default is 0.0. I really don't have any idea what it does or what it should be set to. Thanks again for sharing your post with me. It's been super helpful. Matt
 
I just wanted to connect the sub LP output to both DAC outputs. In a schematic I would just connect the two using wires (same net). However in TI GDE, a wire only connects point-point, so I used a "stereo split mux" to duplicate the LP signal and then tied the unused mux input to "0" using the coefficient "C" block.

Did you get the base files from Allo? or do you need them?
 
Oh, I see (sort of). Thanks for the explanation. I have not received the files from Allo but following your diagrams, I think I have it pretty much setup. It makes sense once you know where to start. I have one flow which combines the subs, applies EQ, and the lowpass crossover. I have a second flow which does pretty much the same for the mains, in stereo though. The only part I'm struggling with now is figuring out how to add delay to the mains for integration with the sub. Is that anything you messed with?
 
I think you are right, I just don't understand the units in the components. The help manual indicates the the number entered integer, 1-16 the number of samples the the input is delayed by by I don't know how that correlates to miliseconds. Pac_Dec_Delay makes even less sense to me.
 
Yes, that one is hard to find.

At the top of the GDE select [View] -> [Properties Window] then set the clock rate you want to "true". Typically its set to 44.1Khz, or 48KHz. It's the base freq. So when you 8x interpolate sample an output its based on this rate, and for delays this is the clock period.
 
No problem, happy to help. I've been the recipient of tons of assistance from people on this site so I'm good with returning it.

That is another hard one to find one. The GDE uses "configurations" so you can generate a family of design files from a given base design. Each configuration is usually due to a clock rate difference. When you compile the design, all configurations are generated as well. So you get a set of output files. This is how Allo generates a design file for each sample frequency you pick in Volumio2.
 
I'm trying to wrap my head around the idea of delay as samples rather than time. I think I've got it. If I want 8.25ms of delay and my sample rate is 44,100Hz the math looks like this: .00825/(1/44,000) and I need to delay by 364 samples (actual result is 363.825). Is that right? And based on the number of samples I need to delay by I'll probably need to use Pac_Dec_Delay.
 
It looks like the memory on the DSP might be the limiting factor here, at least for higher sample rates. The instructions indicate that the maximum delay can be determined by multiplying size by pack by decimation minus decimation. So if you don't want to downsample (decimate as I understand) or reduce bit depth (pack as I understand) you are theoretically limited to 512 samples (fewer as the rest of your components eat up memory). However, the instructions also indicate that if you exceed the maximum number of samples an error will be produced when you generate the code. I can set size as low as one, samples to 1584 (8.25ms @ 192k), pack to one & dec to one and there is no error generated. That doesn't make sense. I might just have to go ahead and try and get this uploaded to the allo and see what happens. Any thoughts?
 
TI should have called it a "pico-DSP" as resources are very limited. In my posts I have left the resource dialog box in the pics so you can get an idea of how much is used.

Yes, your interpretation of the pac_dec block looks right to me.

Allo design flow has some linux commands to remove, then find and replace parts of the file to make it suitable for Volumio. As an alternative (and easier) I've attached a "converter.jar" file. It's a java script to convert the TI output to a binary for Volumio to load. It's small but DIY won't allow a .jar to be uploaded so I zipped it. Double click and it'll prompt you for file names, and has file browsing for selection. Much easier, as I use GDE under Windows.
 

Attachments

  • converter.zip
    6.4 KB · Views: 95
thanks for sharing. I'll give that a go. I've been monitoring my resource usage as I go. I set my pac_dec_delay size to 128 which gives me a little wiggle room memory wise but it shouldn't work with my delay samples. I'll post over at the TI forums (if I can) and see if someone can tell me why GDE is not generating the error the instructions say that it will. If I get an answer I'll post it here.
 
Brutefir2 V0.4.4

I've installed the newer V0.4.4 to try it out. In particular the convolution engine.

I created an impulse wav file from RePhase. It was a 16K tap mono 32b LPCM file. In the BruteFir plugin advanced settings, I set internal res=64b, and all I/O=32b_LE, and specified the same mono file for both R+L.

It's not obvious but as soon as you save settings the volume drops but the play volume indicator does not change (small issue). Just ignore the dial and re-adjust volume back up. I had to use 4 partitions, it would not work with the default 8 partitions, I got playback gaps and eventually silence. The filter created has 16K taps, but I needed to select 8K filter size otherwise I got echos. Resampling at 48K works. It sounds correct with these settings.
 
I would give Moode a go, over Volumio, as the general consensus is that it sounds better and it certainly is lower on resource usage. As well, it is much more cutting-edge and current with a far more frequent update cycle.

I believe Tim is incorporating chip DSP now [Allo, among others)
 
Last edited:
Does anyone know of a working convolution engine for RPI, Volumio, and Piano2.1 ???
ConvoFS.net works for me on the pi3 (another one than my streamer), I haven't tried the Volumio plugin but my impression is that convofs is more flexible in that you can upload a whole set of filters and it will automatically pick the right one for the current rate. You can also activate subsequent upsampling per rate, and it is totally indifferent of the player (volumio, moode, rune or something completely different). It also removes the load from the player.
 
Last edited:
I would give Moode a go, over Volumio, as the general consensus is that it sounds better and it certainly is lower on resource usage. As well, it is much more cutting-edge and current with a far more frequent update cycle.

I believe Tim is incorporating chip DSP now [Allo, among others)

Thanks. When its available for download again, I'll try it out. I think I tried it before Piano2.1 DSP was supported and decided on Volumio. I may also have a problem getting a convolution engine running on it, which I need. I find Linux audio confusing.
 
ConvoFS.net works for me on the pi3 (another one than my streamer), I haven't tried the Volumio plugin but my impression is that convofs is more flexible in that you can upload a whole set of filters and it will automatically pick the right one for the current rate. You can also activate subsequent upsampling per rate, and it is totally indifferent of the player (volumio, moode, rune or something completely different). It also removes the load from the player.

Thanks for the URL, I'll have a look at it. BruteFir2 also has up sampling in the plugin. I typically stay with one sample rate (48KHz) as I move between a PC and the RPI to compare the filters.