[MrSlim]

Since reading these threads, I thought I would look into my own config a bit more.  I decided to give Lubuntu a try since it leaves Pulse audio out of the base distro. I was able to get it set up and playing without resampling with DeadBeef (44.1K file in, 44.1K  output shown in   /proc/asound /card1/pcm0p/sub0/hw_params).  Now, not content to leave well enough alone, I've re-installed Lubuntu 64bit, and I can't get back to that point. Here's my config:
 
 
@linux-dt:~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: USB [E-MU 0204 | USB], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
 
@linux-dt:~$ cat /etc/asound.conf 
defaults.ctl.card 1
defaults.pcm.card 1
defaults.timer.card 1
 (to use the E-MU 0204 as default)
 
Using the DeadBeef config as an example (gmusicbrowser gives the same result), 
(with ALSA resampling turned off, and the resampler deleted from DSP), the sound is ok if I select  "E-MU 0204 Default Audio Device" as the output dev, but I see that it is being resampled :
 
@linux-dt:~$ cat /proc/asound/card1/pcm0p/sub0/hw_params 
access: MMAP_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 16384
 

If I select "Front Speakers" or "Direct Hardware without any conversions" I can see that it is not being re-sampled: (BUT)....
 
@linux-dt:~$ cat /proc/asound/card1/pcm0p/sub0/hw_params 
access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 1024
buffer_size: 8192
 
The but is that the sound is distorted/static/slow...  like something is being intermodulated with it?  
I did notice this as I was sorting it out originally(on 32bit), but didn't take a note of what I did, and I thought adding the /etc/asound.conf config was what solved it the first time..
 
Any Ideas would be appreciated.. 

 

JD

 

[KimLaroux]

What if you don't use /etc/asound.conf this time around? I've been using Kubuntu 64 bits for a few years now and never had to use it. I actually didn't even know this file existed. I always use ~.asoundrc to configure alsa.
 
Do you get the same weird sound with another program, or just DeadBeef?
 
Maybe I'll get a USB cable and try your setting, see if I can replicate. If it's a bug with the EMU, there might be documentation about it on the ALSA wiki.

 

[gustmahler]

Quote:

I'm not sure what you mean by writing that your files now play back at "half velocity". I suspect you mean that the sampling rate is no longer 88.2k but 44.1k on playback?

 
Hello Rizlaw
 
This is meant literally: When I delete Resampling from the DSP list, music plays half velocity (everything plays lower and slower).

 

[gustmahler]

Quote:

 I'm wondering, did you activate Resampling or EQ before you deleted them as per the post you referred to above from Kim Laroux? If you did, perhaps a setting in some deadbeef config file was changed which is causing the problem, now that you have removed Resampling and EQ. 

 
Rizlaw,
No, I did not change them. I did not even know that they are there, never looked into DSP before.

 

[TwinQY]

I can confirm that the half velocity speed thing happens with some DACs on my deadbeef setup, namely portable stuff. I just set the card back to default settings with alsactl init card*. It shouldn't happen if you have either the Resampling DSP or ALSA resampling enabled. Both must be disabled to reproduce this. It seems to happen whenever I repeatedly switch from a 96K or a 192K back to something lower, and back again. Strangely, my DAC1 has never had this happen. 

 

[Rizlaw]

Quote:

 
Rizlaw,
No, I did not change them. I did not even know that they are there, never looked into DSP before.

 
OK, I understand. TwinQY in post # 65 above confirms the problem occurs with some portable DACs:
 
Quote:

I can confirm that the half velocity speed thing happens with some DACs on my deadbeef setup, namely portable stuff. . . . Strangely, my DAC1 has never had this happen.

 
Perhaps your Creative E-Mu is the issue?  As I noted before, whether I had "Resampler" in the deadbeef DSP section or not, I did not experience your problem. This suggests, to me, that the issue may lie with your DAC and how it is handling the bits received. One way to determine if it's your DAC, is to try a different external DAC.
 
To the best of my knowledge, direct hardware ALSA playback (i.e., hw:x,x) bypasses all mixers. Therefore, another suggestion for troubleshooting your issue: install the latest version of Quodlibet: https://code.google.com/p/quodlibet/
 
 

   Quod Libet:   (a) click on the Music menu > Preferences > Player tab
                          (b) for the "Output pipeline" type "alsasink device=hw:x,x"
(omit quotes and substitute your sound device's numbers for "x,x". If needed, use command "aplay -l" from a terminal to find your sound device's "x,x" settings)

I've found that if you haven't altered your distro's basic installed sound system (i.e., removed Pulse Audio, modified ALSA config files, etc.), and your sound card is properly recognized by Linux, quodlibet, set to ALSA hardware direct output works to provide "bit perfect output".
 
Quote:http://thewelltemperedcomputer.com/KB/BitPerfect.htm

Most of the time bit perfect playback refers to the absence of any type of DSP (Digital Signal Processing) like volume control, sample rate conversion, dither, etc.

True bit perfect playback is sending the audio file unaltered to the audio device.
Bit depth, sample rate, number of channels and the format should remain unaltered.

This of course requires the hardware to match the properties of the audio source exactly.
 
Do observe that bit perfect playback is about the samples played without any DSP applied. It says nothing about the accuracy of the time step.
As PCM audio is samples with a fixed sample rate; perfect playback is bit perfect and time step perfect.

 
Playing a 16 bits audio file on a 24 (or 32) bit DAC is not bit perfect by definition as to play it, 8 zero bits must be appended to each sample.
However appending 8 zeros won’t alter the sound.
It might even be beneficial as you can use these eight bits for 48 dB volume reduction without loss of resolution.

 

[MrSlim]

Quote:

What if you don't use /etc/asound.conf this time around? I've been using Kubuntu 64 bits for a few years now and never had to use it. I actually didn't even know this file existed. I always use ~.asoundrc to configure alsa.
 
Do you get the same weird sound with another program, or just DeadBeef?
 
Maybe I'll get a USB cable and try your setting, see if I can replicate. If it's a bug with the EMU, there might be documentation about it on the ALSA wiki.

 
Gmusicbrowser was doing the same thing...

Well, that seems to have solved the problem, but it didn't work right away which was weird..  I renamed asound.conf and then rebooted, just to make sure. After the reboot I tried DeadBeef and it was doing the same thing, so I tried gmusicbrowser, and it worked, using hw:1,0, and I could see that the sample rate was correct on the output..  Then I tried DeadBeef and it worked too..  so problem solved, not sure why the lingering problem.. but Thanks!

 

[Rizlaw]

Quote:

 
Gmusicbrowser was doing the same thing...

Well, that seems to have solved the problem, but it didn't work right away which was weird..  I renamed asound.conf and then rebooted, just to make sure. After the reboot I tried DeadBeef and it was doing the same thing, so I tried gmusicbrowser, and it worked, using hw:1,0, and I could see that the sample rate was correct on the output..  Then I tried DeadBeef and it worked too..  so problem solved, not sure why the lingering problem.. but Thanks!

Contrary to what many think, quickly rebooting a computer does not completely wipe DRAM memory of what your OS was running. DRAM does retain information for some time after a power down and certainly after a reboot which normally does not involve a power down. I recall a few years back some security researchers demonstrated how sensitive data could be recovered from computers that were shut down, if one could quickly freeze the memory and run some security tools to recover data most would have thought gone after a power down. Here's an article about it: http://www.zdnet.com/blog/security/cryogenically-frozen-ram-bypasses-all-disk-encryption-methods/900
 
I've found, in situations like yours where I've change a setting in the OS, then performed a quick reboot that the change, although present, didn't always work right away. But, a shutdown for several minutes fully cleared memory and a restart correctly picked up the change and everything was back to normal. This is also why Cable Modem Techs will always recommend completely removing AC power from a cable modem to clear a problem.  IMO, I think you experienced the same thing. Good to hear everything is working again.

 

[gustmahler]

Rizlaw: Thank you very much. 
 
I am using a Beresford Caiman DAC, connected by USB. I had to look up the number from Terminal, it found three outputs, from all the the numbers provided, I suppose x,x means "card no.","device no.", which for USB is 2,0
 
So I installed Quod Libet and set 
Output pipeline" type "alsasink device=hw:2,0"
 
This worked. I got the audio on my equipment. Quod Libet is a very nice player. Thank you for the tip. The only thing I miss is, it to tell me what hz/bit it is actually playing. Is there no option for that?
 
Now I still do not know what went wrong in Deadbeef, as it seems it is not the DAC's fault, if Quod Libet really is playing 88200/24.
 
Thanks

 

[Rizlaw]

Quote:

Rizlaw: Thank you very much. 
 
I am using a Beresford Caiman DAC, connected by USB. I had to look up the number from Terminal, it found three outputs, from all the the numbers provided, I suppose x,x means "card no.","device no.", which for USB is 2,0
 
So I installed Quod Libet and set 
Output pipeline" type "alsasink device=hw:2,0"
 
This worked. I got the audio on my equipment. Quod Libet is a very nice player. Thank you for the tip. The only thing I miss is, it to tell me what hz/bit it is actually playing. Is there no option for that?
 
Now I still do not know what went wrong in Deadbeef, as it seems it is not the DAC's fault, if Quod Libet really is playing 88200/24.
 
Thanks

 
I'm glad to hear you got Quodlibet to work.
 
 
Quote:

Originally Posted by gustmahler 
 
. . . i Quod Libet really ... playing 88200/24.
 
Thanks

 
If you're unwilling to believe the read out of you DAC and really concerned about double checking quodlibet for bit perfect playback, you can try this:
 
Quote:http://thewelltemperedcomputer.com/KB/BitPerfect.htm

Testing bit perfect playback

Either you believe you have your configured your system right or you proof it.
This can be done by playing a file.
Record the digital out of your sound device.
Load both the original and the recorded file in an audio editor.
Time align (crucial, they must start with the same sample at the same time)
Subtract the tracks.
If  you don’t  end up  all samples being zero, there is a difference so the recording is not bit perfect.
This is called the null test.

 
 
 
Quote:

Originally Posted by gustmahler 
 
 The only thing I miss is, it to tell me what hz/bit it is actually playing. Is there no option for that?

 
 
Unfortunately, each Linux music player seems to be missing one or two features that are found in the other players. Each development/design team seems to have different ideas of what a player should have in terms of features. In Quodlibet's case, there is no plug-in, for displaying real time file info like bitrate and sampling frequency (a la deadbeef). It's also missing a spectrum analyzer (a la Guayadeque - another excellent player) and it has no super terrific "now playing" feature a la gmusicbrowser. Although the last item can be made up for by using Conky.
 
As for your continuing deadbeef issue, have you tried removing the deadbeef config files?
Open Nautilus, simultaneously press the "Ctl" and "H" keys to reveal hidden "dot" files/folders and navigate to:

/home/.config/deadbeef

You should see two folders and three files (config, dspconfig and socket) in the /deadbeef folder. Try temporarilly moving the 3 files to your trash bin, shut down your computer for about 1 minute to fully clear DRAM. Restart your computer and open deadbeef, it should re-create the 3 missing files with default settings. Select your DAC as before and see if it works. You should NOT have to touch anything in the DSP folder. If it doesn't work, restore the 3 files from the trash bin or perform a complete uninstall of deadbeef with Synaptic Package Manager. Note that a complete uninstall, like Windows, doesn't always uninstall the config files, so you should double check that the uninstall also removed the deadbeef folder from the above indicated location in your /home folder. You can then opt to reinstall deadbeef or stay with Quodlibet or some other player that appeals to you.

 

[gustmahler]

Thank you Rizlaw. I will try Deadbeef after removing the config file.
 
The problem is, the Beresford DAC has no display. As far as a read out by ear is possible, yes I believe I have a more intense listening experience now. A better way to tell may be that HD files are playing much louder now - I suppose that should be the case with 24bit audio.
 
Telling by sound quality is often difficult. Because a 24/88,2 HD audio file does not tell you how good the recording equipment and setting was. It is often surprising how good a standard audio CD can sound, if a well playing orchestra is recorded properly. Most CD's lack the one or the other or even both and of course this does not sound better with whatever high bit and sampling rate

 

[Rizlaw]

Quote:

. . . . A better way to tell may be that HD files are playing much louder now - I suppose that should be the case with 24bit audio. . . .
 

In my own experience, I haven't found 16 bit and 24 bit audio files of the exact same recording to have noticeably different recording levels. I'm sure different masterings of the same recording can and do make a difference. I have noticed, in some cases, that 24 bit files of pieces tend to be quieter and more resolved than their identical 16 bit counterparts. However, most of the time, I'm simply not that impressed by most "hi-rez"  music I buy from places like HDTracks and Classics On Line.  However, given the way you originally described your problem, I can understand why it would now seem "louder".

 

[Jonas Kienitz]

You really helped me Thanks a lot!!!

 

[Hark3n]

Howdy people,
 
Just a quick rundown of my experience with Linux audio.
 
Short version: A ******** mess.
 
Long version:
 
I've been running Linux for a good couple of years now. Mainly Kubuntu, but have dabbled in some other flavours. Anyway, recently I started to get the audiophile itch again, and this time simply decided to scratch. Bought myself a pair of HD439's and a FiiO E10. Yes, tight budget.
 
So, seeing that I use Linux, I started to peruse a couple of sites to find out how I can decent sound from Linux. Obviously this thread has been super helpful.
 
So, I finally have bit-perfect audio caressing my ears. I'm now balder than when I started this exercise, but it work.
 
OK, what I did.
 
First off, PulseAudio is nice, on the surface, but between last night and this morning it just simply decided that my E10 is not a valid device anymore. Tried everything, but only silence eminated from my headphones.
 
ALSA seems to be the best option for decent audio on Linux. I uninstalled PulseAudio and reverted to pure ALSA. It worked. Only problem is that it now lists about 25 audio devices in my device tree. Simple matter of testing each one and seeing what works and what don't.
 
After that it was over to finding the best player. For years I have been a staunch devotee to Amarok. Brilliant player with exceptional media library functions. Only problem is that it passes everything through its own mixer and highest output, according to the cat command, is only 16/48. That is while playing 24/192 audio. Also, for some reason the SQ is really bad. Allot of distortion. Enough so that I can hear it over my cheap desktop speakers. And it is not a volume problem. Even turning it down still result in serious distortion.
 
So with that I said goodbye to Amarok as my player of choice, although I still use it for music management, and setting off to find a new player.
 
First I tried VLC. Brilliant little program that. Plays anything you throw at it, and does it all in bit-perfect goodness. Only problem is that media management with it sucks, big time. Big deal breaker for me. It will still be my default video player, but for music, nope.
 
Then I came upon this thread and saw someone mention DeaDbeef. Tried it, love it, will continue using it until foobar2000 comes to Linux. Bit-perfect output, decent playlist display, brilliant sq and eq.
 
So, to sum up. Use clean ALSA for sound. It's a bit more hands on with settings, but that is alright concidering what mess PulseAudio is. It is like a woman during pms. Freaking unstable. Smallest little change in your setup and it gets a fanny-wobble of epic proportions.
 
For playback DeaDbeef is pretty much the closest thing to fb2k in Linux at the moment. I tried Audacious, but it is ugly. DeaDbeef also handles fb2k eq settings, so that has to count for something.
 
Thanks to all on this thread whose advice and guidance has helped me in getting decent sound out of my setup.

 

[TwinQY]

+1 for Deadbeef! I own a similar setup to yours (FiiO E10, bass-modded HD428), and it sounds pretty damn good, well, as good as the HD428s have ever sounded. Sometimes with the E10 on ALSA though, playback speed gets doubled at arbitrarily random occasions. I just reset the device back to default, but some might view it as annoying. Thankfully, I've never messed with pulseaudio at this point 

. Probably a better solution exists, but I don't use the FiiO enough to warrant finding out why.