This is very well the case. Perhaps you can sent doctormord your serious measurements proving what you experienced.
It requires some effort to get these pi-hat combos going. That - many of us experienced during the HifiBerry project. And it doesn't mean that there aren't better solutions out there.
Hi folks.
Brief update.
Been playing around with Clives' kernel .
Note: Earlier mentioned /boot/config.txt entry for the MamboBerry needs to be in place on your PI!
Result:
Above shows the MamboBerry playing 384k data.
On Linux & LMS 7.9.0 systems, the /etc/squeezeboxserver/custom-convert.conf entry for server based upsampling could look like below:
If you swap 384000 with 96000 you'll be able to checkout the block integer division patch
as supplied by Clives' kernel.
Enjoy.
Brief update.
Been playing around with Clives' kernel .
Note: Earlier mentioned /boot/config.txt entry for the MamboBerry needs to be in place on your PI!
Result:
Code:
root@alpha ~ # cat /proc/asound/card0/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 384000 (384000/1)
period_size: 15360
buffer_size: 61440Above shows the MamboBerry playing 384k data.
On Linux & LMS 7.9.0 systems, the /etc/squeezeboxserver/custom-convert.conf entry for server based upsampling could look like below:
Code:
flc flc * *
# F
[sox] -D -q -t flac $FILE$ -t flac -e signed -C 0 -b 24 - rate -v -s -L 384000 2>/tmp/lmssoxsrc.logIf you swap 384000 with 96000 you'll be able to checkout the block integer division patch
as supplied by Clives' kernel.
Enjoy.
Just tried DSD/DoP on the Mamboberry LS.
Ok.
I just own a single DSD album from OPUS3 in DSD128. That's not much of a DSD collection. And lets not talk about the type of music on that disk.
DSD128 requires a samplerate of 352.8 for DoP.
I thought I might give it a try. 384 works quite well now.
I installed the DSD plugin on LMS 7.9.0 and restarted squeezelite adding "-D" to rest of the bunch.
That was it!??!? Yep, that's all it was.
As expected, playback runs at samplerate 352.8:
Great. Now I got DoP on my HAT.
Enjoy.
Ok.
I just own a single DSD album from OPUS3 in DSD128. That's not much of a DSD collection. And lets not talk about the type of music on that disk.
DSD128 requires a samplerate of 352.8 for DoP.
I thought I might give it a try. 384 works quite well now.
I installed the DSD plugin on LMS 7.9.0 and restarted squeezelite adding "-D" to rest of the bunch.
That was it!??!? Yep, that's all it was.
As expected, playback runs at samplerate 352.8:
Code:
cat /proc/asound/card0/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 352800 (352800/1)
period_size: 14112
buffer_size: 56448Great. Now I got DoP on my HAT.
Enjoy.
Last edited:
Yes, DSD64 == DoP@176k4 and DSD128 == DoP@352k8 was always supported from day zero, when the DSD/DoP support was first added to squeezelite. Most people were only ever outputting DoP via USB interfaces.... WaveIO, Amanero, JLSounds..... etc, etc.
The top of the range Sabre, ES9038, ISTR, supports DoP input directly as well as native DSD and PCM. It's just a shame that the Open Source driver, NDA, blah, blah situation is such a PITA with the ESS chips.
@Clive. It's your 4.4.y-simple kernel and its 384k support which made DSD128/DoP possible.
###############
###############
Folks.
I now tried the last item on my checklist.
Some background first.
Ralphy - the guy who maintains squeezelite nowadays - introduced a function to his sources, which reads stream format data (e.g. samplerate) from the pcm stream header.
This function had been developed by Marco Curti.
The problem on the LMS had been, that server based upsampling of PCM/.wav data didn't work
in the past. The server wouldn't tell squeezelite what's coming. That ended into a mess-up.
For quite some time Marco offered his own patched squeezelite version.
Luckily this function has been merged into Ralphys sources nowadays.
By using "-W" as squeezelite start option you'll enable that function . (I'm not sure why this functionality is not enabled by default)
Basically a custom-convert.conf rule like:
Will lead to 384kHz towards the DAC:
Test passed! Great.
Enjoy.
###############
###############
Folks.
I now tried the last item on my checklist.
Some background first.
Ralphy - the guy who maintains squeezelite nowadays - introduced a function to his sources, which reads stream format data (e.g. samplerate) from the pcm stream header.
This function had been developed by Marco Curti.
The problem on the LMS had been, that server based upsampling of PCM/.wav data didn't work
in the past. The server wouldn't tell squeezelite what's coming. That ended into a mess-up.
For quite some time Marco offered his own patched squeezelite version.
Luckily this function has been merged into Ralphys sources nowadays.
By using "-W" as squeezelite start option you'll enable that function . (I'm not sure why this functionality is not enabled by default)
Basically a custom-convert.conf rule like:
Code:
flc pcm * *
# F
[sox] -D -q -t flac $FILE$ -t wavpcm -e signed -b 24 - rate -v -s -L 384000 2>/tmp/soxpcm384.logWill lead to 384kHz towards the DAC:
Code:
root@alpha ~ # cat /proc/asound/card0/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 384000 (384000/1)
period_size: 15360
buffer_size: 61440Test passed! Great.
Enjoy.
Last edited:
So....what i realy need to install or write to play 384k ?@Clive. It's your 4.4.y-simple kernel and its 384k support which made DSD128/DoP possible.
###############
###############
Folks.
I now tried the last item on my checklist.
Some background first.
Ralphy - the guy who maintains squeezelite nowadays - introduced a function to his sources, which reads stream format data (e.g. samplerate) from the pcm stream header.
This function had been developed by Marco Curti.
The problem on the LMS had been, that server based upsampling of PCM/.wav data didn't work
in the past. The server wouldn't tell squeezelite what's coming. That ended into a mess-up.
For quite some time Marco offered his own patched squeezelite version.
Luckily this function has been merged into Ralphys sources nowadays.
By using "-W" as squeezelite start option you'll enable that function . (I'm not sure why this functionality is not enabled by default)
Basically a custom-convert.conf rule like:
Code:flc pcm * * # F [sox] -D -q -t flac $FILE$ -t wavpcm -e signed -b 24 - rate -v -s -L 384000 2>/tmp/soxpcm384.log
Will lead to 384kHz towards the DAC:
Code:root@alpha ~ # cat /proc/asound/card0/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S24_LE subformat: STD channels: 2 rate: 384000 (384000/1) period_size: 15360 buffer_size: 61440
Test passed! Great.
Enjoy.
Can someone explain in details for all the people who are not from electronics like me how to do it.
Just tried DSD/DoP on the Mamboberry LS.
Ok.
I just own a single DSD album from OPUS3 in DSD128. That's not much of a DSD collection. And lets not talk about the type of music on that disk.
DSD128 requires a samplerate of 352.8 for DoP.
I thought I might give it a try. 384 works quite well now.
I installed the DSD plugin on LMS 7.9.0 and restarted squeezelite adding "-D" to rest of the bunch.
That was it!??!? Yep, that's all it was.
As expected, playback runs at samplerate 352.8:
Great. Now I got DoP on my HAT.Code:cat /proc/asound/card0/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S24_LE subformat: STD channels: 2 rate: 352800 (352800/1) period_size: 14112 buffer_size: 56448
Enjoy.
Off Topic ---- But so you prefer the Raspberry Pi 2 over the Pi 3 ? And could you tell us why?
You need to talk to the Moode, Rune, Volumio, Archphile, PiCorePlayer maintainers
to introduce the above mentioned kernel and related configuration options.
For all of them it's a piece of cake to do that update. The more people start bugging
them, the greater the chance you'll get it.
The problem they'll probably have with it, is that potentially rather "static" nature of that kernel tree. But. As soon as they all agree that's worth it, as joined force they might be able to get the stuff pushed into the common RPI kernel tree. Clive had his doubts some time back that this gonna happen soon.
However.
I suppose Moode has it in already. I'm not 100% sure though. You need to ask Tim.
Here is a blog about some of the differences.
On the first glance the PI3 looks quite good.
Let's have a look at it from my perspective.
1. powerconsumption almost doubles (see link above) under load, 20%+ if idle (ref)
2. temperature goes up
3. no performance improvements on the peripherals - USB/ethernet (bottlenecks)
4. no improvements on the board layout (Odroid C2 almost runs twice the speed)
5. no improvements on the onboard power situation
6. WLAN and Bluetooth are potential sources of noise and also draw more current
7. USB/ethernet combination as bad as ever
8. still inefficient RAM used
9. can't turn off power led
10. and there's probably more ( I sent mine back before running into more stuff )
With a little tweaking my PI2 comes very close to the PI3 stock performance.
At playback I'm running just about 0.5% CPU load. I do not use the PI
for server and DSP (SRC) duties -- and wouldn't do so.
What more do I need?
For me there's no reason to jump on that PI3 train.
However. I really hope that the PI4 will evolve into the Odroid-C2 direction.
Than, why not buying an Odroid-C2??
It's not just the HW which makes a system. No other board comes close to the PI SW and community support. No other board offers more gadgets.
@ 10million units sold by now, the RPI is and will remain the leading force in the market for quite some time.
What would I do if I hadn't several PI2s at hand!?!? @Amazon.de the PI3 currently sells for 10€ less then the PI2. I think I'd go for the PI3 and try to squeeze the best out of it.
Enjoy.
Last edited:
Ok thank you very much. I will ask on other foruns.
About moode, i tested the last version with the 384k on sox but nothing happens. The output is only 192.
OK, thanks for responses...... Have you had trouble syncing your Pi with other Squeezebox Touches or Other Pi's for that matter ? --- If not, where is the best place to report the problem?
Just tried DSD/DoP on the Mamboberry LS.
Ok.
I just own a single DSD album from OPUS3 in DSD128. That's not much of a DSD collection. And lets not talk about the type of music on that disk.
DSD128 requires a samplerate of 352.8 for DoP.
I thought I might give it a try. 384 works quite well now.
I installed the DSD plugin on LMS 7.9.0 and restarted squeezelite adding "-D" to rest of the bunch.
That was it!??!? Yep, that's all it was.
As expected, playback runs at samplerate 352.8:
Code:cat /proc/asound/card0/pcm0p/sub0/hw_params access: MMAP_INTERLEAVED format: S24_LE subformat: STD channels: 2 rate: 352800 (352800/1) period_size: 14112 buffer_size: 56448
Great. Now I got DoP on my HAT.
Enjoy.
Hi,
Are u sure ALSA is outputting DoP format and not just plain PCM? I didn't think es9023 could decode DoP.
If I output DoP using MPD to Mambo DAC+ es9023 all I get is bunch of noise. If I turn DoP off then I see MPD decodes 2x-rate DSD to 705.6kHz PCM (5.644 mbps sample rate) and then ALSA outputting 352.8 kHz PCM and music comes out of the DAC.
-Tim
Hi Clivem,
did you try to push your kernel changes upstream?
It would be really nice to have all these extra overlays in default kernel source!
I will play the soonest possible with your kernel sources and if everything is good, I will icnlude this kernel in next Archphile image. However it could be better if all these goodies were accepted upstream.
Last edited:
It's a long story, but the simple answer, yes. I have tried to get 384k support accepted by both downstream (RPi) and upstream, because downstream wouldn't take the changes unless upstream approved them. But I ended up banging my head against a brick wall with ALSA dev mailing list.
Yes, of course. But I am not a masochist! I try. Then I give up. I don't keep wasting my time.
I have made available the 384k patch set, the ES9023 patch set, the simple-card patch set, individually and via my rpi-4.4.y-simple branch. This is what I use. It works for me. I cannot provide any support. If it works for you, great! If it breaks, you get to keep both pieces.
I have neither the time or the will, to play the upstream game. I have tried. I will continue maintaining the patch sets outside of the RPi kernel tree. It is a shame that only a limited number of people will benefit from functionality that is possible with many of the 3rd party hardware DAC boards that are being made available for the Pi, because it is not made available by the "official" RPi kernel sources.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.