• 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

Jump to Latest
#61
MPD tinny audio with 16-bit files

I've been investigating the 'MPD tinny sound with 16-bit files' issue. I think it comes down to period_size being too low.

When MPD plays a 16-bit FLAC file the following hw_params are used:
Code: 
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 90
buffer_size: 22050
When the same file is played with aplay using:
Code: 
flac -d <16bit-flac-file> -c | aplay -
I get:
Code: 
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 2048
buffer_size: 32768
With mpd (both mainline and my version) the music sounds tinny, with aplay it sounds good.

Any thoughts?
 
#62
lintweaker: sorry, I've missed your post...

in the mpd.conf there is following line:

# BOTIC fixup: request the lowest period time
period_time "1"

you can try to increase it for increasing period size

but I think the easier solution (for now) is to force 32 bit output using

format "*:32:*"
 
#63
alsa patches for mainline

Hi Miero,

ALSA tools/libs etc 1.0.28 are out but are still limited to 384kHz. I think it would be a good idea to post your patches for 768000 support. There is now a even a affordable mainstream DAC/headamp combo (iFi micro iDSD) available which supports PCM 768k and DSD512.

If you do not have the time, I won't mind picking this up.
 
#65
Having taken delivery of a BBB I installed from meiro's website the 'as is' Botic distribution yesterday - no problems encountered so thanks for the efforts there.

Over the last few weeks, in anticipation of the Botic cape appearing I've been thinking about how I will control the solution. My preference is a UPnP/DLNA solution and I've been happily using BubbleUPnP as a control point for a while now.

On a couple of Raspberry Pi based renderers I use I've recently switched to Volumio 1.4 as it includes a UPnP/DLNA capability that routes music through to the mpd-based Volumio player. This works very well. I reasoned that conceptually the Botic and Volumio solutions are similar, being customised/optimised Debian distributions so I investigated the Volumio UPnP module;

An UPnP Audio Media Renderer based on MPD

I installed upmpdcli on my BBB by following the install instructions for the Raspberry Pi on the Downloads page and, hey presto, I appear to have a functioning BBB with Botic software and UPnP functionality; I say appear to have because I haven't actually got any audio output kit hooked up to the BBB so I can't hear the ouput but BubbleUPnP sees the device, serves flac files to it and reports playback progress and on the BBB the activity LEDs suggest things are happening.

As UPnP/DLNA is an obvious and established approach to controlling the Botic I thought this might be of interest to others; perhaps someone can give it a listen too?

If there is sufficient interest in this approach it might even be worth including it, or something similar, in the Botic distribution to provide 'out of the box' control functionality as with the Volumio solution?

Cheers

Ray
 
#67
twluke said:
Just off-topic but sorry to say that I've been just wondering why you are calling miero as meiro. Respect for the author might include writing his handle name correctly. 😱
Click to expand...

Thanks for pointing out my typographic errors; I have always had a 'blind spot' for some letter combinations and I will try to proof read more carefully in future. There certainly wasn't any disrespect intended and, hopefully, none taken?

Apologies again.

Ray
 
#69
I've been following this for some time with interest. I want to interface the BBB to a WM8741 DAC rather than the ESS you're targeting. Are your driver/modifications open source? If so can you please post a link so I can adapt your work as I need?

Thanks
Simon
 
#70
komri: Everything that has been published has also source code included in the /sources directory of the SD card image.

However, in the latest published version there is no I2C control enabled, so it might work without changes with your WM8741 if it is set in the autodetect mode. Just connect needed signals.

I do not have Opus DAC, so I cannot test this.
 
#71
Miero,

Thanks for the reply. I don't have a BBB yet so had been looking for an online repository. I'll get a BBB and then see the files. Yes it's the I2C control I'd like to use; I don't have alsa coding experience but lots of C so I expect I can modify your ESS code for the WM when it's available.

Thanks
 
#73
It depends how do you define a "driver". Everything needed is public, but its usage is not simple.

This week I'd like to publish next version based on kernel 3.16.1 which has some improvements in the McASP code and I hope it could resolve occasional underun issues.
 
#75
Driver update is not yet ready, but it is slowly "growing"... 🙂

Meanwhile I have discovered that those occasional underruns can be fixed by playing audio with realtime priority (works well even without RT kernel), e.g.:

$ chrt 1 play xyz.flac

For multichannel hd audio one would need to increase also cpufreq, but in the next version I expect the 8ch of 192kHz/32bit stream will be fine.

I've not tried MPD with "chrt", but I think it would require also internal changes for that. But there is at an experimental support for that somewhere: [CuBox] Real-time Kernel and Tuning | Voyage MuBox

lintweaker, would we be able to support realtime priorities for player threads in mpd-dsd?
 
#76
miero said:
Driver update is not yet ready, but it is slowly "growing"... 🙂
...
lintweaker, would we be able to support realtime priorities
for player threads in mpd-dsd?
Click to expand...
That would be possible, probably best to make a separate branch for it.

But before we go to that route, have you tried it to see if it helps enough? You could use the patched source version of mpd-0.17.6 from Voyage Linux which is my enhanced version of mpd-0.17.6-dsd with RT+buffer patch added. (http://www.voyage.hk/dists/experimental/mpd/mpd_0.17.6-1.tar.gz). mpd.conf needs additional configuration as well.
 
#77
miero said:
I've not tried MPD with "chrt", but I think it would require also internal changes for that. But there is at an experimental support for that somewhere: [CuBox] Real-time Kernel and Tuning | Voyage MuBox
Click to expand...

Maybe you need to know this url to get rt patches for MPD covering 0.17 to 0.19 versions.

BTW, in order to take the best advantage of these patches, you'll need an rt kernel, 3.14.12 as of this writing. Otherwise maybe better off waiting for probably forthcoming rt patches for 3.16 kernel.

twluke
 
#78
patched mpd with rt support

I managed to patch my mpd-0.18.6-dsd version with the RT patch for mpd-0.19 (after some manual tweaks and changes). It is now playing without interruptions while compiling MPD. Not sure if that was possible before.
 
You must log in or register to reply here.
Top Bottom