How to get high quality audio from R-Pi?


66 posts   Page 3 of 3   1, 2, 3
by Wanderlei » Thu Aug 23, 2012 4:39 am
fredjam wrote:What don't you understand? You can get high quality sound from the HDMI connector.
Many recent sound systems accept a HDMI connection and can use the high quality sound
it provides.


That what I was trying to say and that it is just small link in the chain of having "good quality audio". So if he dosnt have the other equipment for "good quality audio", he wont get it. Just need a receiver that has HDMI and he is golden.
Posts: 79
Joined: Tue Aug 21, 2012 2:01 pm
by fredjam » Fri Aug 24, 2012 12:05 am
If you don't have a hi-fi system that accepts a HDMI input then you can still get high
quality sound by going through your HDMI TV or monitor. Just feed the audio output
form the TV or monitor into one of your your amplifiers input sockets. Of course it all
depends on what you mean by high quality. I mean at least good CD audio quality.
Posts: 83
Joined: Thu Jul 19, 2012 3:19 am
Location: London UK
by mahjongg » Fri Aug 24, 2012 12:16 am
Just google for "hdmi to sound adapter", but remember that the PI can only provide a maximum of 200mA to such a device (if your PSU is up to it, that is), so maybe you need one that is externally powered.
With such an adapter you should get sound exceeding CD quality.
User avatar
Forum Moderator
Forum Moderator
Posts: 5693
Joined: Sun Mar 11, 2012 12:19 am
by Redshift187 » Fri Aug 24, 2012 7:20 pm
The analogue output is capable of higher quality than it comes with.
Note: these improvements involve voiding your warranty.

First, C34 and C48, part of the bandpass filter, also removes any DC component from the audio. However, immediately after that are 4 diodes (in two packages, D12 and D13). These are meant as voltage clamps, but they clamp the now AC signal to between 0.6V and 2.7V (clipping all of the negative half of the waveform, and adding a DC component back that changes with the sound being played). Removing these diodes is the first step.

Second, C34 and C48, being 10uF, work with R20 and R26 to form a high-pass filter, limiting the low end of the bandwidth to approximately 100Hz. If you were to replace these capacitors with 47uF ones, you would have low end down to about 22Hz.
Posts: 3
Joined: Fri Aug 24, 2012 7:10 pm
by gritz » Fri Aug 24, 2012 9:39 pm
Redshift187 wrote:The analogue output is capable of higher quality than it comes with.
Note: these improvements involve voiding your warranty.

First, C34 and C48, part of the bandpass filter, also removes any DC component from the audio. However, immediately after that are 4 diodes (in two packages, D12 and D13). These are meant as voltage clamps, but they clamp the now AC signal to between 0.6V and 2.7V (clipping all of the negative half of the waveform, and adding a DC component back that changes with the sound being played). Removing these diodes is the first step.

Second, C34 and C48, being 10uF, work with R20 and R26 to form a high-pass filter, limiting the low end of the bandwidth to approximately 100Hz. If you were to replace these capacitors with 47uF ones, you would have low end down to about 22Hz.


Edit: You're right about the diode network - it will clamp at 1 diode drop below 0V. I'd just written some blah about clamping at the supply rails and then realised that the diodes are after the coupling cap. Hang on though - R20 and R21 form a voltage divider that cut the 3v3/2 negative excursion by about a third, so maybe it's not a big deal. The bav99 is a silicon diode with a Vf of about 0v6, so it shouldn't be too troubled. Bit messy though...

Re the 10u cap: Yes and no.

If the output is plugged into a line input at an impedance of ~10k ohms then the -3dB freq. will be in the order of 1.59Hz (with a caveat regarding my mental arithmetic...) Good enough to listen to that album of whale song. ;)

If the output is supplying a set of low impedance headphones (at say 16-32R) then yeah, it will be rather toppy. I'm not sure there's room on the board for a pair of 1000u caps though! Also, looking at the lpf and whatnot I'd wager the output's not really designed with low impedance headphones in mind anyway. I don't remember the current sourcing ability of the BCM's PWM outputs, but I expect they're fairly non-zero output impedance too.
Posts: 449
Joined: Sat Jan 28, 2012 2:33 am
by Redshift187 » Fri Aug 24, 2012 11:14 pm
gritz wrote:Edit: You're right about the diode network - it will clamp at 1 diode drop below 0V. I'd just written some blah about clamping at the supply rails and then realised that the diodes are after the coupling cap. Hang on though - R20 and R21 form a voltage divider that cut the 3v3/2 negative excursion by about a third, so maybe it's not a big deal. The bav99 is a silicon diode with a Vf of about 0v6, so it shouldn't be too troubled. Bit messy though...

Re the 10u cap: Yes and no.

If the output is plugged into a line input at an impedance of ~10k ohms then the -3dB freq. will be in the order of 1.59Hz (with a caveat regarding my mental arithmetic...) Good enough to listen to that album of whale song. ;)

If the output is supplying a set of low impedance headphones (at say 16-32R) then yeah, it will be rather toppy. I'm not sure there's room on the board for a pair of 1000u caps though! Also, looking at the lpf and whatnot I'd wager the output's not really designed with low impedance headphones in mind anyway. I don't remember the current sourcing ability of the BCM's PWM outputs, but I expect they're fairly non-zero output impedance too.


Perhaps the diode network doesn't have that much effect, but IMO it's entirely unnecessary and I don't like any sort of asymmetrical clamp on an audio signal.

As for the line impedance, it should be orders of magnitude away from R20 and R26 (150R), so the filter frequency would be set by approximately 150R. 150R and 10uF has a -3dB of about 106Hz.
Last edited by Redshift187 on Fri Aug 24, 2012 11:23 pm, edited 1 time in total.
Posts: 3
Joined: Fri Aug 24, 2012 7:10 pm
by Redshift187 » Fri Aug 24, 2012 11:22 pm
Really though, neither of my suggestions had a huge impact. It sounds better with both (I just tried), but there's still a crackling that sounds like bad clipping happening somewhere else. I guess I'll just wait for the USB audio capability, since I have a few decent sounding DACs lying around.
Posts: 3
Joined: Fri Aug 24, 2012 7:10 pm
by gritz » Fri Aug 24, 2012 11:40 pm
Don't fret - the analogue out is never going to be great with only 11 bits. In addition, there might be issues with the low level PWM engine, the ALSA layer, interrupt handling or a combo of allsorts causing your crackling. The analogue out is a bit of a waste of space IMO.

On the bright side, USB handling seems to be improving, so don't lose hope!
Posts: 449
Joined: Sat Jan 28, 2012 2:33 am
by XploD » Fri Oct 19, 2012 4:37 pm
Oh I was inactive for a while and you have entered into deatils and wrote a lot :D

First of all, what is a high quality (at least for me)? I think that PC/laptop's out is something normal. The sound must be crystal clear, and smooth, without A SINGLE stutter/click/pop during playback. This is a good quality. I repeat, everything worse than standard laptop's output is not worth listening for me. Somebody mentioned FM tuners. I don't listen to tuners but the built-in FM tuner on my hi-fi sounds better than PI's analog out.

To conclude, HDMI is the best audio out so far? If it is, I'll have to use HDMI, at least for now. I have a Sony TV through which I can forwad audio to my Hi-Fi (I don't have AV Receiver, just a micro Hi-Fi system from Philips - it does have a HDMI but just output because it's a dvd player too). But I was scared that TV will mess audio quality. But when I tried listening to music through TV (from TV's USB player) it does sound a lot better than Pi's analog out. The song is crystal clear (no noise) and if there is a lack of bass or treble, I can fix it by playing with hi-fi's equilaizer.

Now I started using Spotify as a main source of music so I'm thinking about Despotify on PI, controlled by TV's remote through HDMI-CEC. Later I'll buy HDMI to audio out and use some android app to control it that I can power off my TV.
Posts: 23
Joined: Sat Mar 17, 2012 12:14 pm
by Narf03 » Fri Oct 19, 2012 7:32 pm
I noticed the analog sound quality of Pi has been improved a lot lately, but there is still pop sound when starting /ending music, using mplayer so far, I think it's doing better than omxplayer in term of quality. I think if given more time, they should be able to improve it to pc quality.
Posts: 230
Joined: Mon Jun 11, 2012 3:44 pm
by XploD » Sat Nov 10, 2012 11:49 am
I finally tried HDMI output and yes, it works well :) Even more, there is a newer version of Raspbmc since last time I used it which works even better, without stuttering and pause between songs. Even HDMI CEC works out-of-the-box and wi-fi should work OOTB too. I only noticed when the song starts playing it stutter just once and that's it. It's not a problem but it could be due to my power supply (5.5V 800mA). I'll buy stronger power supply soon.

The thing that shocked me yesterday is a fact that there is no GUI based player in raspbian (I tried new raspbian with 1 GHz OC). Terminal-based player? Come on, this is the stupidest thing I've ever seen :mrgreen: But I'll be using Raspbmc anyway so it doesn't bother me, just made me and my friends laugh hard. When I finally managed to play track, I felt like I've been coding a mp3 player myself :lol:

Now I'm waiting for Raspbmc team to fix last.fm scrobbling issue to start using it as a main player. This bug is present a long time ago, I don't know why it haven't been fixed yet :( I contacted the developer and ask him if he could fix it.
Posts: 23
Joined: Sat Mar 17, 2012 12:14 pm
by usverg » Sat Aug 24, 2013 6:40 pm
Here is my samurai path how I achieved good sound using raspberry PI + EMU 0404 USB. Seems it works fine until 192/24 sound. So here is what I did:

1) installed raspbmc 'from stock'

2) sudo apt-get update && sudo apt-get install alsa mpg123 flac mplayer mpd mpc ftp curlftpfs

3) sudo nano /etc/mpd.conf
removed format, and everything related to mixer in alsa audio_output, so its section now looks like:
audio_output {
type "alsa"
name "My ALSA Device"
device "hw:0,0"
}

also following values changed so:
mixer_type "disabled"
audio_buffer_size "8192"
buffer_before_play "30%"

4) sudo nano /etc/modprobe.d/alsa-base.conf
options snd-usb-audio index=-2
changed to
options snd-usb-audio index=-1
(that makes USB audio to be default output device when connected)
and added:
options snd-usb-audio nrpacks=1
(some magic value that removes occasional clicks during playback, and also it removes "delay: estimated" garbage from syslog). BTW increasing this value to ~15 causes 192/24 to play fine, but RPI soon stucks/reboots and corrupts its SD card. And also while 192/24 plays, other (lower) formats played with clicks.

5) put hacks and hacks.pl files into /etc/init.d from this archieve..
hacks.zip
hacks & hacks.pl
(1.3 KiB) Downloaded 53 times

..and execute following:
sudo chmod +x hacks
sudo chmod +x hacks.pl
sudo update-rc.d hacks defaults
this makes hacks.pl to run in background and it does following: waits for ftp server availability, then mounts ftp folder and also controls video output and stops/starts xbmc when TV is off/on, this allows using this RPI not only as music player via USB soundcard, but also as XBMC for connected TV (in this case sound goes via HDMI).

6) sudo nano /boot/cmdline.txt
not it looks so on my system:
dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2 rootfstype=ext4 persistent-logs elevator=deadline noatime quiet rootwait sdhci-bcm2708.enable_llm=1 dwc_otg.microframe_schedule=1 dwc_otg.fiq_fix_enable=1

7) prepared FTP server (I'm using filezilla server for now): limited download speed for raspberry to 512KB/s and reduced buffers to 4KB. I did this to prevent curlftpfs from excessive downloading data from server at maximum speed that overloads raspberry's bus. It would be good if curlftpfs had such an option but it doesn't.

8) sudo reboot

9) ta-da!

PS I tried raspyfi but didn't succeed - EMU 0404 sounds buzzing when play at any rate except 44100 with it. Seems raspbmc has some specific patches in kernel, may be I will try some other experimental kernels for RPI, for for now I'm happy with what I did.
Posts: 3
Joined: Sat Aug 24, 2013 6:24 pm
by usverg » Sun Aug 25, 2013 6:58 pm
Today I compiled kernel from 3.8.y branch and found that big nrpacks value still causes sound clicks, also it still causes delay: estimated 0.. records to flood syslog. Then I decided o revert back to 3.6.y, but before compilation I removed (commented) following code lines in linux\linux\sound\usb\pcm.c:
if (abs(est_delay - subs->last_delay) * 1000 > runtime->rate * 2)
snd_printk(KERN_DEBUG "delay: estimated %d, actual %d\n",
est_delay, subs->last_delay);

then compiled and installed this kernel, changed nrpacks to 10 and found that sound still good at any rate, and futhermore I can now listen 192/24. IMHO excessive debug messages that I commented caused SD card writes that subsequently caused rare 'clicks' in sound.
Now I'm looking a way how to avoid ANY writes to SD card except may be some configs, like MPD DB - to eliminate even probability of such problem.
Posts: 3
Joined: Sat Aug 24, 2013 6:24 pm
by sbp » Mon Aug 26, 2013 10:47 am
Hi - very interesting.

Just to understand.
These changes you made before compiling and the positive results were that obtained in kernel 3.8?

Do you think it also will help in kernel 3.9.y?

Steen
piCorePlayer webpage: https://sites.google.com/site/picoreplayer/home
Posts: 95
Joined: Wed Sep 26, 2012 7:54 pm
by usverg » Mon Aug 26, 2013 11:39 am
Nope, this changes and positive results were on modified 3.6.11. As for 3.8 - I tried it AS IS w/o any changes and since it didnt fix anything - I decided do not use it and moved experiments back to 3.6.11 but modified it.
BTW I'm not experienced linux user, I'm from-Windows-world C++ programmer so for now I'm hardly looking how to avoid any SD card IO when it not neccessary. Later I will try to recompile kernel with disabled printk(), swapping (BTW, is there swap on RPI at all? swapon -s does't show any for me), on-disk FS caches (SMB definately use it, not sure about fuse/curlftpfs.
Ideally it would be nice to have RPI on completely read-only SD'card and MPD-related and may be some other configs on mounted network pathes. Except no-SD-writes this also will make 'RPI-player' immune to hard power-offs.
Posts: 3
Joined: Sat Aug 24, 2013 6:24 pm
by FM81 » Mon Aug 26, 2013 12:57 pm
@usverg: I've set up an old Version-1-256MB-raspberry nearly same way as you described. Before there was also a little "click" on every write-access to SD-card.
Solution: The system is stored at a read-only mounted SD-card. '/var/' lives in RAM only. The music is stored on an USB. database and statefile and so on came from USB too (other partition), but will be copied to RAM during MPD-start. During MPD-stop (this is the only moment, when something is mounted read-write) database and statefile and so on goes back to USB. '/etc/init.d/mpd' was modified to realize all these things.
For safe shutdown I've included a NiMH-battery and some scripts/binaries, so I can simply cut the power.
Soundcard is an UCA202 from Behringer (PCM2704 based?).
I've running this since more than 7 months, the kernel-version and all related things are a little bit older (end of 2012?). Since I'm not sure, if it would make problems, to switch to newer versions, I see no reason to do so at this point. But if wished I can search and post all related things, they should also work on newer versions.

I know, this is no audiophile solution, but works fine for me and I can not hear any difference between real CD-Player and this. More I didn't need ... :)

MfG, FM_81

PS: An important hardware-related thing on such such setups is: AVOID ANY GROUND LOOPS! It's much better as using a ground-loop-isolators after all ... :)
A: What does the command 'cat /dev/urandom', can you tell me please?
B: Yeah, that's very simple: It feeds your cat with radioactive material!
Posts: 196
Joined: Wed Apr 17, 2013 4:33 pm