• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Support for Botic Linux driver

BB CPU power usage during upsampling?

Hi,

I have a question to those who tested upsampling functionality with BB and Botic distro using libsoxr resampling library.
Do BB has sufficient CPU power to upsample let’s say 16/44,1 to 16/176,4 kHz?
If so how much CPU usage is needed to do that. Is it possible to upsamle even 16/44,1 to 352,8kHz? How much power (%) is used then?
Regards,
bern
 
Miero , will you be kind enough to add I2C controller for opus DAC to switch between PCM and DSD without the need for using hardware switches?
It looks like you set the MODE switch to the middle setting, then hook up the lines, to me. Address(es) are on page 21 of the data sheet (bridging CSB looks to only be needed to use 2 DAC son the same I2C bus). I hope it's that simple, because I'm seriously considering an Opus for a BBB, ATM :).
 
kinku: I'm trying to extend driver to allow something more generic for such cases. Stay tuned.

bern: No, the resampling to the highest quality by SoX requires more CPU power than BBB has (it uses double precision 64bit floating numbers, but BBB has HW acceleration only for single precision 32 bit float numbers).
 
bern: No, the resampling to the highest quality by SoX requires more CPU power than BBB has (it uses double precision 64bit floating numbers, but BBB has HW acceleration only for single precision 32 bit float numbers).

So as I suspected upsampling with highest quality is impossible with current BB CPU power…
But what about upsampling 44,1 streams/files to 176,4kHz? Is BB with Botic have enough power to do this task?

I use Raspberry B+ with squeezelite and upsamling 44,1 to 176,4kHZ is a problem for RPi. It takes 10 sec. to start playing 44,1khz file with 100% CPU load for the first seconds of playing. After that CPU stabilize at 41% CPU usage and files are played normally.
Upsampling from 44,1 kHz to 88, 2 kHz is done smoothly.
I use following parameters for upsampling with RPi and squeezelite:
Code:
mI:::28
explained HERE

Asuming that BB has twice CPU power than Rpi do you think that smooth upsampling from 44,1 to 176,4kHz would be possible with BB and Botic?
 
The reason I think it is possible is because I see code like this:

Code:
#if HAVE_DOUBLE_PRECISION
void _soxr_deinterleave(double * * dest, /* Round/clipping not needed here */
soxr_datatype_t data_type, void const * * src0, size_t n, unsigned ch)
{
#define DEINTERLEAVE_TO double
switch (data_type & 3) {
case SOXR_FLOAT32: DEINTERLEAVE_FROM(float, 0); break;
case SOXR_FLOAT64: DEINTERLEAVE_FROM(double, 1); break;
case SOXR_INT32: DEINTERLEAVE_FROM(int32_t, 0); break;
case SOXR_INT16: DEINTERLEAVE_FROM(int16_t, 0); break;
default: break;
}
}
#endif
#if HAVE_SINGLE_PRECISION
void _soxr_deinterleave_f(float * * dest, /* Round/clipping not needed here */
soxr_datatype_t data_type, void const * * src0, size_t n, unsigned ch)
{
 
The only reliable way is to try it on BBB if the "m" setting works.


Could you please test squeezelite "medium" quality upsampling in Botic and share results?
I don’t have BBB yet so I cannot do this myself…
It would be interesting to know whether 16/44,1 files can be played with 88,2; 176,4kHz and so on without issues.
For testing could you build squeezelite player from source as optimal as possible (I assume for ARMv7A architecture)?
Russ White said:
Assuming a person really wants to re-sample on the fly - one could probably rework SoX to use 32bit FP. Or one could re-sample ahead of time and not on the fly.
Software (on the fly) upsampling have many advantages: Most lossless files are still rips from CD which are 16/44,1kHz. After accurate rip to eg flac files are still 16/44,1kHz and take relatively moderate disk space (comparing to 96khz or 192khz files).
Upsampling should well worked with NOS DAC (minimal digital filters approach). In this case NOS Dac is fed with 'upsampled content' which does not need further digital processing/manipulation in DAC and as consequence should have a positive effect on the sound quality.
 
But "medium" quality upsampling does not have positive effect on the sound quality IMHO...

I am quoting John Swenson from link I posted in #524:

These stand for "very high", "high", "medium", "low" and "q"

A word on these, the differences are not necessarily related to how they sound, they refer to how far the aliases are attenuated (remember the engineering community regards the alias attenuation as the primary figure of merit for a filter). These primarily relate to how long the filters are. All these filters work by performing calculations on a series of samples in the file, the longer filters use more samples, the shorter filters use fewer samples. The greater the alias attenuation the longer the filter has to be. This CAN affect what you hear. Do not just blindly use the "very high" setting, it may not be the best sounding.
So maybe it is worth to try sampling parameters which John propose as starting point?
 
Miero/Russ:
I have been using sox for about 18 months for another audio processing activity. I spent quite a bit of time googling and the conclusion I (sadly) came to is that sox's internal data format is 32-bit integer, though so far it has worked quite well for my needs. It appears some specific functions (like gain/attenuation) might convert to/from floating point (64-bit) but not all. Thus, it would seem that BBB's lack of 64-bit float is not an issue in the case of BBB resampling.

I'll admit to not having opened the source code (trying to avoid the swamp-and-alligators problem), so I can't say definitively. However several of the postings I've found appeared to be from those involved in development.
 
Hi miero. I've heard mention that Botic V4 will include a UPNP/DLNA capability?

And closely related, will Botic V4 incorporate an update of mpd? It seems that some people are experiencing glitches when using upmpdcli to achieve upnp/dlna capability with the current Botic release and the upmpdcli author suggests that the underlying issues (with curl) are fixed with mpd 0.19.9

Thanks as always.

Ray
 
Last edited by a moderator:
True, but it would be nice to have everything in one easy package - especially for people like me who have never used Linux before.
Runeaudio's maintainer has been in here, and at least had plans for support being integrated into a future image. That or Volumio supporting it would be the easiest ways to go about it, without needing to have Linux knowledge or experience. You'd just need the file shares.
 
Nautiboy - DLNA/UPNP can be installed by the user. Miero does not really need to include them. apt-get works great!

Yes, I know, have been running UPNP on top of Botic for a while now; good results on my system with upmpdcli or gmediarenderer. I was just asking if there is any mileage in what I've heard about this functionality being integrated into the next Botic release - I'm sure it would make life easier for some people.
 
Runeaudio's maintainer has been in here, and at least had plans for support being integrated into a future image. That or Volumio supporting it would be the easiest ways to go about it, without needing to have Linux knowledge or experience. You'd just need the file shares.

There may be a dependency on the version of mpd being used in Rune or Volumio that makes including the botic into those products problematic? see my post from earlier on.