That smells like a MPD issue to me with 352k8/384k. Switching to hifiberry-dac overlay and not specifiying 384k param to the overlay will result in 192k max.
I don't have a Mambo but I have extensively tested with 5 other ES9023 boards @ all sample rates 32-384k and 16/32 bit depths.
On my rpi-4.4.y simple branch, MMAP is enabled by default with I2S driver and the i2s-mmap overlay is removed. (The I2S backport code enables MMAP by default.) On RPiF default rpi-4.4.y build, the i2s-mmap dtoverlay is used to enable MMAP for I2S data transfer. I forget why the Pi people disabled it by default. I think there was one card that had issues with capture (not playback) when MMAP was enabled.
So Clive, in your experience, it is safe to always enable MMAP. I will look into doing that for piCorePlayer. 🙂
thanks and regards
Could be the Mambo. SC had same result with LMS but he didn't mention whether he was using DAC+ or LS board. Maybe when he returns from his vacation he can add some detail.
The only other 9023 dac I have is a USB ODAC and no issues with 24/192.
-Tim
AFAIK, it was only ever disabled due to a capture issue trying to record, not playback. I never heard of there ever being any issue with playback. It saves a little CPU overhead. And I'm surprised it never got re-enabled by default, (although I might have had something to do with it being re-enabled by default without the overlay), especially as SonicPi wouldn't work without MMAP. And there are probably way more SonicPi users than audiophools. 😉 Yeah, if I was you, I'd whack the "dtoverlay=i2s-mmap" into your default config.txt. As I said, it is going to go away in the future. I've pretty much switched all my Pi installs to running 4.7.4 now, rather than 4.4.21. In 4.7 the option and overlay are gone. MMAP is enabled by default. (The I2S/dma/clockmgr backport, resolved the original issue that got it disabled to start with.)
Hmmm. I wonder whether the chap/company (Colibri????) behind the Mambo would send me one for testing? I'm loathe to want to buy another ES9023 based HAT, as I already own a few........
Ah, thanks. I remember from earlier post you mentioned that its default .
Is cat /proc/asound/card0/pcm0p/sub0/hw_params the way to verify MMAP?
When I run cmd I see:
access: RW_INTERLEAVED
-Tim
I think they would.
info@collybia.com
Emilios is who I've chatted with in the past. I think Vasillis is the hardware guy.
You are looking for, MMAP_INTERLEAVED
Code:
$ cat /proc/asound/PianoDAC/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 4096
buffer_size: 16384I might be misunderstanding when mmap is automatically enabled but I'm not seeing it.
This is DAC+Pro playing 24/192
Linux 4.4.20-sc1 armv7l Architecture
pi@rp6:~ $ cat /proc/asound/sndrpihifiberry/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S24_LE
subformat: STD
channels: 2
rate: 192000 (384000/2)
period_size: 16384
buffer_size: 65536
pi@rp6:~ $ cat /proc/asound/card0/pcm0p/sub0/hw_params
same
pi@rp6:~ $ cat /boot/config.txt
hdmi_drive=2
force_turbo=1
arm_freq=1000
core_freq=500
sdram_freq=450
over_voltage=2
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=audio=off
dtoverlay=hifiberry-dacplus
This is the kernel SoundCheck built from my rpi-4.4.y-simple branch? MMAP should be enabled by default, unless your playback software is disabling it. What are you using, MPD? Is there an option in MPD config, like there is in squeezelite, eg. "-a ::0", that would be disabling it when sound device is opened?
Yes MPD and y looks like MPD controls the setting. I'm running .19 and when I add use_mmap "yes" to mpd.conf I get mpd crash and syslog error below.
Sep 19 21:12:55 rp6 mpd[3466]: config_file: unrecognized parameter in config file at line 35: use_mmap
In MPD news for .20
http://git.musicpd.org/cgit/master/mpd.git/plain/NEWS
...
* output
- alsa: fix multi-channel order
- alsa: remove option "use_mmap"
- alsa: support DSD_U32
- alsa: disable DoP if it fails
...
so maybe its also disabled in .19 but either way it appears to be player controlled.
Yes, I think you need to look to the MPD developers for support. It seems as though they don't want you to be opening the ALSA device with MMAP enabled......
Hi folks. I'm back.
I was wondering if there are any news around the 192kHz issue Tim and I ran into with the 4.4-simple kernel from two weeks ago?
Clive - Did you find anything ??
I was wondering if there are any news around the 192kHz issue Tim and I ran into with the 4.4-simple kernel from two weeks ago?
Clive - Did you find anything ??
I'm confused. The is the HB DAC+ thread, right? The 192k issue.... This is the one where Tim said, "After testing the only issue I've run into so far is that on Mambo DAC+ 24/192 bit rate audio from flac files sounds greatly slowed down when using the custom overlay (with or w/o params)." So it was Mambo and 192/24 that was slowed down?
Emilios sent me a Mambo LS for testing. I tested every possible sample rate and bit depth combo with simple tree build, from 32-384k, at 32/24/16 bit depths. No issues for me with testing. No issues for me when playing back 192/24 material using squeezelite. Is this something you are experiencing with MPD as the playback software?
A bit lost with alot of fragmented information and not much time searching for the time being unfortunately...
Is the hifiberry digi+ PRO supported with 384k in clivem's - simple kernel?
Is the hifiberry digi+ PRO supported with 384k in clivem's - simple kernel?
Thanks - good to know 🙂
BTW: Here are a small test and some measurements of the rpi3 with dac+ Plus
Archimago's Musings: MEASUREMENTS: Raspberry Pi 3 & HiFiBerry DAC+ Pro (Audio Streaming)
BTW: Here are a small test and some measurements of the rpi3 with dac+ Plus
Archimago's Musings: MEASUREMENTS: Raspberry Pi 3 & HiFiBerry DAC+ Pro (Audio Streaming)
LOL. Forget the measurements, best thing about that "review", is his taking aim at the audio prophet, HansB, "Maybe he should take a moment and use the testing equipment in the background of the video and see what he finds..." Superb!!!!!
Last edited: