Brutefir via squeezelite?

[Mervin Beng]

Hi all. This is just at the conceptual stage.

My previous setup was an x86 server with LMS+brutefirdrc serving SBTouch in two rooms. That has been pulled apart, and I've moved to temporary premises for a while. When we move back I'm thinking of setting up two or more rooms, but using a much lower power (greener) server, perhaps a Chromebox.

I'd much prefer brutefir to run on the client, and I've been using a Pogoplug with great success as an SBT replacement. This will not have the power to run brutefir, but a low end Chomebox certainly will. Squeezelite has an option to output to a pipe instead of device, so squeezelite | brutefir (or a revised brutefirwrapper) looks feasible.

Does anyone have thoughts on this? With this approach I think configuration, scalability (CPU load for EQ), testing, etc are potentially more straight forward than via EQ on a server.

Regards,
Mervin

[Olav Sunde]

Hi Mervin

This is a good idea.
I actually had a mail exchange with 'triode' or Adrian about this last year where I asked if it would be possible to adapt the already present soxr I/O in squeezelite for a modified brutefirwrapper. In a reply Adrian mentions the version of squeezelite that can output to stdout, but also says :

"Other than this, the process.c code in squeezelite was written with the idea of other processing code in mind - it would be possible to extend this to add in more processing.  However not sure what bruteDRC would need - I've not looked at it."

I then discussed this a little with Klaas, but after that I have not done anything. I would need some help adapting brutefirwrapper to work together with squeezelite. Klaas and Toby are both busy elsewhere so I have not moved this forward.

The most elegant way would, in my view, be to have brutefirwrapper receive from and return to squeezelite so that squeezelite still handles interfacing with ALSA and brutefirwrapper does it's magic with brutefir.

Regards
Olav

[Mervin Beng]

Hi Olav,

This is the approach which I was thinking of. In effect, after squeezelite we create a pipeline almost exactly as LMS would, squeezelite -> (revised) brutefirwrapper -> aplay (to alsa device). As the existing wrapper handles gapless, error logging, etc, in theory it looks simple. If squeezelite outputs in .wav with enough info (sample rate, format is the minimum), then piping into a wrapper should be fine. If it only sends raw PCM then we have problems, as brutefir requires the input stream to be a particular format (was it 32 float??) if I recall.

I won't be spending a lot of time on this, but will keep the group posted as I start experimenting.

Mervin

[Olav Sunde]

Yes, you send from stdout of squeezelite to brutefirwrapper, then let brutefir handle ALSA? This is also a good possibility. I have also been thinking of running two instances of squeezelite with brutefirwrapper in between, but then we would have to ask Adrian to make stdin as an option for us. Keep us posted...

Olav

[Mervin Beng]

As you've already been in touch with Adrian, can you please contact him to request for what should be a relatively simple enhancement:

For output to stdout, allow output in .wav format, i.e. pcm with the wav header that provides sample rate and format info. This allows stdout to pipe easily into aplay, sox and brutefirwrapper.

If you can copy me on the message, it would be great. With this option, I think building a client-based brutefirdrc should be quite feasible.

Regards,
Mervin

--
You received this message because you are subscribed to the Google Groups "BrutefirDRC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brutefirdrc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mervin Beng]

The added advantage of this capability is that the music can be passed on without resampling. which is highly desirable.

Mervin

[Olav Sunde]

Hi Mervin

I have not contacted Adrian yet, but will do. Please look at the code here https://code.google.com/p/squeezelite/source/browse/output_stdout.c
Unfortunately I do not 'read' code easily. Does this do what you need for testing or is this stripped pcm?

Olav

[Toby Dickenson]

brutefir needs the brutefirwrapper when it is used in the server audio
pipeline because it has to deal with the gapless splicing of separate
streams, one per track, at possibly different bit rates.

Putting brutefir into the squeezelite output stage makes things alot
easier. I expect it would see a continuous stream unbroken by track
boundaries, and all upsampled to the selected output device bit rate.
You shouldnt need brutefirwrapper at all - just a suitable brutefir
configuration file. This is the normal way brutefir really expects
itself to be used.

[Olav Sunde]

Hi Toby

what if squeezelite does not upsample to a known rate, but instead inputrate=outputrate? This is how squeezelite works in my system. Would you not need the wrapper to handle all variables?

Olav

[Mervin Beng]

Thanks for the input.  Yes, an unvarying output format from squeezelite has advantages, and makes potentially eliminates the need for a  brutefir wrapper. Just one DRC filter at the upsampled rate will do, and gapless is implicitly provided for. I believe the format will need to be changed (I recall brutefir wants 32-bit float), but that's trivial.

My audiophile instinct was to keep output sample rate and format same as input for as long as possible, but squeezelite might be an ideal point in the pipeline to upsample before output before EQ. I'll give it a try, perhaps piping to aplay. If that works, piping into brutefir is almost a given. I'm curious this upsampling will affect 44.1/16 audio significantly.

Mervin

[Toby Dickenson]

> squeezelite might be an ideal point in
> the pipeline to upsample before output before EQ. I'll give it a try,

> I'm curious this upsampling will affect 44.1/16 audio significantly.

It is a better bet than relying on your output device to handle 44.1 :-(

[Mervin Beng]

Ah... here we're getting into the quirks of audiophilia, where enthusiasts will claim 'bit-perfect' while oblivious of the number of conversions along the pipeline :) :)

Olav - yes, I'll approach this new experiment using a fixed rate/format from squeezelite, so we don't have to ask Triode for any additional feature.

The stdout approach basically works - I've tested with aplay. The issue I have is that my laptop's squeezelite does not seem to have libsoxr (sox resampling) compiled in, so it's sending to stdout in original format. I'll have to recompile a version which does resample later and test further.

Cheers,
Mervin

[Olav Sunde]

Upsampling and sample rate conversion is dabated a lot these days :>) I think upsampling can sound good. Using native rates depends very much on how filtering is done in your converter. Meridian, Ayre and others use asymmetric filters to get better sound quality. My Devialet amp sounds very good with redbook material. I do not know which filter characteristics Devialet uses. If one can keep upsampling within a frequency family, i.e. 44.1 is 88.2,  176.4 or even 352.8 and 48 is 96,  192 or 384, then this can work well.
I do believe it would be good to have the option to use native rates. This will no doubt complicate things compared to the very elegant solution of going direct to brutefir. Another question is if the ALSA interface of brutefir is as good as the one in squeezelite. My experience is that squeezelite is extremely robust and stable.

Olav

[Mervin Beng]

I have just recompiled squeezelite with resampling, then removed pulseaudio to test piping to alsa directly (after upsampling). It works. Squeezelite offers a nice range of upsampling options, so we may even get a 'bonus' in terms of upsampling capability:

SoX 14.4 High Quality:	No options (this is the default setting)
SoX 14.4 High Quality (Aliasing Enabled):	-b 90 -a
SoX 14.4 VHQ Linear Phase:	-v -s
SoX 14.4 VHQ Intermediate Phase:	-v -s -I
SoX 14.4 VHQ Minimum Phase:	-v -s -M

We can either use brutefir's alsa output, or perhaps better, pipe into aplay, which has has pretty good control of the output device:

squeezelite -o - -r 96000 -R X -f 32 | sudo aplay -D hw:0,0 -r 96000 -f S32_LE -c 2

In this test, I've confirmed that the output card (0,0) really does stick at 'native' 96000 sampling rate and 32-bit words. Conceptually a pipeline like squeezelite | brutefir | aplay should work well. I'll focus on aplay for final output because it has known ability to adjust buffer timing, etc, which is needed for some async USB dacs.

Regards,
Mervin

[Olav Sunde]

Mervin, this is very promising! I am looking forward to more reports as you get progress. Do you think the possibility to pipe back into squeezelite from brutefir would have any advantages compared to using aplay for ALSA  interfacing? I use this command line to run squeezelite via ALSA to the USB input of my Devialet:
squeezelite -o hw:0,0 -n player -r 192000 -a 80::: -c pcm,flac -b 50000:50000 -p 75 -s server &
The -a 80 (ALSA buffer time) is necesary to avoid 'clicking' through the Devialet. -b 50000:50000 sets squeezelite up as sort of a memory player and works very well indeed.
If you wanted to keep the input rate as output, will brutefirwrapper need much rebuilding? You'd probably need a helper script to run squeezelite + brutefir with all the options anyway so this could be added to a rewritten brutefirwrapper..

Olav

[Kari Hämeenaho]

I have found that using ALSA loopback works much better than pipes, see http://forums.slimdevices.com/showthread.php?97046-Announce-Squeezelite-a-small-headless-squeezeplay-emulator-for-linux-(alsa-only)&p=816962&viewfull=1#post816962

In that post there is also a control app source code to handle (re)starts and changes of the filters by HUP signal (restarts current song from beginning with new settings). It also supports setting roomcorrection on/off (off means that brutefir is not run).

[Olav Sunde]

Very nice Kari

only problem might be the need for upsampling to a fixed sample rate. Brutefiewrapper has a lot of code to handle sample rates (and bit depths) to pass through processing at the files native spec. I'd prefer letting the DAC or amp (do you own a Devialet Kari?) receive the original file specification. But maybe I am out of touch with reality here?

Regards
Olav Sunde

[Kari Hämeenaho]

Yes, I know that brutefirwrapper can do that, but it makes it complex too. But my way of upsampling has also one bad side, the unit running squeezelite with upsampling needs quite a lot processing power, my four core cubox-i-4pro has ehough power, may could use also resampling to 192kHz, but that is quite close to maximum. For my dac it does not seem to be issue to do the resampling (with sox high quality setting), I have a simple DIY DAC (XMOS usb input and pcm5102 connected with i2s). But for my system the ALSA loopback keeps the timing (some kind of jitter) of the the output much better than using pipe for connecting squeezelite and brutefir . The timing problems seem to happen in the pipe, at least as far as I could analyse it. If devialet has buffering and reclocking, then you may not have the timing issue at all. Anyway it would be interesting to hear does the same improvement happen if brutefirwrapper is modified to use ALSA loopback too, at least for systems that dont have super smart DACs.

Regards

Kari Hämeenaho

[Olav Sunde]

I am not against upsampling as such. My Devialet amp upsamples everyting to 192kHz (and the Devialet monos to 384kHz).. but I'd still prefer a general solution that, as a minimum, keeps this within a frequency family. I.e. 44.1, 88.2, 176.2 and 48, 96, 192. I do not know if this is possible or even necessary. Maybe it is better to upsample and then fine tune brutefir for best possible performance and sound?
At any rate, a lot of purists will want output to be same as the input and let the playback hardware do the rest. There is no re-clocking in Devialet amps. Probably buffering. They use an Xmos USB device.
Brutefirwrapper + ALSA loopback sounds exiting, but it depends on Toby having interest and time.

Regards
Olav Sunde

[Kari Hämeenaho]

Well, it is kind of opinion what you count as hardware: as far as I know  Linn DS and even your Devialet do handle the upsampling in software, not really hardware. So the diffrerence doing it in another embedded device practically zero, in my system squeezelite and brutefir run in a device looking like hifi device with 7 inch LCD display for displaying music information. But as I dont know the algorithms for the upsampling in Linn/Devialet, so I do like the sox solution, at least I have the source code and can look what it does. And with sox I can even control the upsampling quality by parameters. I do own one Linn DS device too, and it sounds better with upsamping when  using external DAC, as far as I know the upsampling is on always in analog outputs.

I also think that XMOS actually always does reclocking as asynchornous USB does not carry hardware clock signal, but the amount of buffering and circuitry after the XMOS can be different.

Regards

Kari Hämeenaho