OK, after much fluffing around I managed to get a 24/96 FLAC file onto the BBB and play via FFMPEG.
There were a couple of glitches but otherwise actually sounded pretty good tho not my style of music man! Anyway it proves the drivers work and are installed properly which was the aim. Now to try and get Squeezelite working with it.
But a rest first to read GLT's new posting on his blog - looks interesting!
There were a couple of glitches but otherwise actually sounded pretty good tho not my style of music man! Anyway it proves the drivers work and are installed properly which was the aim. Now to try and get Squeezelite working with it.
But a rest first to read GLT's new posting on his blog - looks interesting!
Known issues:
- 32bit playback does not work well, the 16 and 24 bit works fine
- jitter eliminator must be at maximum possible settings to not drop the samples
- 32bit playback does not work well, the 16 and 24 bit works fine
- jitter eliminator must be at maximum possible settings to not drop the samples
I presume the bit about jitter eliminator refers to the firmware in the ES9018? I am using a ES9023 at the moment.
Yes, Buffalo 3. Another option how to "solve" drops is to bypass oversampling and reclocking... it's strange that it works well, although with smaller bandwidth.
Miero,
Re my Squeezelite problem, I got this back from Triode (guy who wrote Squeezelite):
Try setting different values for the period size via the -a option. You probably need to alter the overall buffer size and the period count to match what the driver supports - these are the first two values in the -a option.
Can you tell me what an appropriate buffer size/period count would be in relation to what the driver supports? These are the 2 values he mentions:
b = buffer time in ms or size in bytes, p = period count or size in bytes
Cheers
Re my Squeezelite problem, I got this back from Triode (guy who wrote Squeezelite):
Try setting different values for the period size via the -a option. You probably need to alter the overall buffer size and the period count to match what the driver supports - these are the first two values in the -a option.
Can you tell me what an appropriate buffer size/period count would be in relation to what the driver supports? These are the 2 values he mentions:
b = buffer time in ms or size in bytes, p = period count or size in bytes
Cheers
Last edited:
Also check if mmap is supported - this is the default for squeezelite to reduce CPU load, but is not for other players such as aplay.
-a :::0 turns off mmap
Adrian (triode)
Code I've wrote is not aware of any maps, periods or buffer sizes. This might be related to underlying McASP driver...
Does the driver have anything in /proc for a stream when running with another player - if so what does it show?
Does this provide anything of value?
Code:
root@arm:/home/debian# speaker-test -c 2 -F S32_LE -r 96000
speaker-test 1.0.25
Playback device is default
Stream parameters are 96000Hz, S32_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 96000Hz (requested 96000Hz)
Buffer size range from 64 to 16384
Period size range from 4 to 1024
Using max buffer size 16384
Periods = 4
was set period_size = 1024
was set buffer_size = 16384
0 - Front Left
1 - Front Right
Time per period = 5.834139
0 - Front Left
1 - Front RightGot it going, sounding really good and no glitches.
After looking at the spreaker_test output I used:
Thanks guys, I think there will be others wanting to use Squeezelite with these drivers/cape so pleased it works.
Adrian, do those values look OK for use here? That was using a 96000 stream, would it need to be changed for 192000?
After looking at the spreaker_test output I used:
Code:
squeezelite -o hw:CARD=Botic -a 16384:1024::Thanks guys, I think there will be others wanting to use Squeezelite with these drivers/cape so pleased it works.
Adrian, do those values look OK for use here? That was using a 96000 stream, would it need to be changed for 192000?
Do you get the same for the hw: device? Try the buffer size and period with the -a option.
Looks good - ignore previous post...
You should be able to find values which work for all sample rates. The buffer time can also be specified in ms - this may help with something which works at all rates.
Depending on you dac you may also want to try resampling to a high sample rate which will work as long as the squeezelite build includes libsoxr support.
Regards resampling - part of this thread is around developing drivers and a HW cape to cape for both the 44.1k and 48k (an multiples) rates as the Beaglebone only has a clock suitable for 48K and, of course, most CD based music is 44.1k.
To date resampling, as far as I can see, is regarded as not exactly High Fidelity. What is your feeling in this regard? Having read (but not fully understood) the upsample section of the community squeeze site I though I may give it a try sometime.
To date resampling, as far as I can see, is regarded as not exactly High Fidelity. What is your feeling in this regard? Having read (but not fully understood) the upsample section of the community squeeze site I though I may give it a try sometime.
Resampling is one of those things that is only as good as the underlying algorithm. Most the ones I have seen for ARM linux are only capable of around 90db DNR... Not really terrible, but not good either. 🙂
Default squeezelite resampling is synchronous - so still needs two hw clocks for all sample rates. The reason for considering sw resampling is the postulation that it may sound preferable to the hardware up sampling filter in the dac chip. If you resample to 384k or 44.1 equivalent then it is likely the dac applies minimum or no filtering of its own. Try it and see..
It uses libsoxr which is quite good - the are lots of options to trade off quality vs CPU load, but the default is quite high quality. Default settings work on a pi so should be ok for BBB. They also work well on a wandboard which is what we are using for CSOS.
Last edited:
Adrian, do you mean synchronous, or asynchronous? I didn't mean synchronous. It is more practical to do very good quality synchronous resampling.
Default is synchronous, but you can specify asynchronous with an extra option. I would test though with the synchronous case.