It all depends on your applications and alsa chain configuration. If your system supports playing multiple streams at the same time, it must resample to common frequency. Therefore, if your system is using pulseaudio (any modern desktop distribution in default configuration) or alsa plugin dmix (the "default" device as defined by alsa packages), it is resampling. If you tell your playback applications to output directly to device "plug:hw:YOURCARDNAME", no resampling occurs for sampling rates supported by your card. But only a single stream can be played (all other concurrent attempts end up with "device busy" error) which is unacceptable for general use desktop.
It is all in your hands
My hands ? oh dear....less coffee.....
So it seems Ubuntu is resampling. Bummer. Well, I only use that PC for music so I'd be happy if all it did was play single stream.
Um, sorry to ask this, but how do I do this for Rhythmbox :
"plug:hw:YOURCARDNAME"
or do I need a different player ?
Sorry for the noob question ! Thanks !
Last edited:
All good !
Yep, I opened up the daemon.conf and 44/16 is what everything is getting resampled to - so no resampling for native 44/16 files. Phew.
I copied and edited the daemon.conf file to use the best quality src. The Atom processor is at 35% just playing tunes. Curiously, the board is Intel D945gsejt which is an N270 single core cpu, but Ubuntu system monitor shoes two cores with differing loads. Odd.
I also followed the instructions you posted and on Linux mint and found my buffer size is 262144 and 131072 so I plugged in 2 and 92.879819 milli secs.
It's all good !I'm gonna play with the settings in the daemon.conf file and see how that affects sound quality and processor load but is all working well so no real need, just curious.
Thank you very very much for your help !
Yep, I opened up the daemon.conf and 44/16 is what everything is getting resampled to - so no resampling for native 44/16 files. Phew.
I copied and edited the daemon.conf file to use the best quality src. The Atom processor is at 35% just playing tunes. Curiously, the board is Intel D945gsejt which is an N270 single core cpu, but Ubuntu system monitor shoes two cores with differing loads. Odd.
I also followed the instructions you posted and on Linux mint and found my buffer size is 262144 and 131072 so I plugged in 2 and 92.879819 milli secs.
It's all good !I'm gonna play with the settings in the daemon.conf file and see how that affects sound quality and processor load but is all working well so no real need, just curious.
Thank you very very much for your help !
The single core uses hyperthreading - two processing pipes. Each pipe has a different load.
The best quality src method is pretty demanding, 35% of atom cpu is no surprise.
Since your playback chain takes so much CPU, I suggest to keep the buffer as large as possible, split to more than 2 fragments, at least 4. This way you minimize the danger of buffer underruns when your system hits load peaks.
Hi,
Ah, that makes sense......the bios has these settings but I was a little confused as I thought it didn't have anything like speed step, but it was just my ignorance....again.
Thanks for the tip. ! Is there any way to track possible underruns by using a code in a terminal ? So far, I haven't heard any deficiencies and in fact, it sounds very good indeed.
Totally Chuffed !
Ah, that makes sense......the bios has these settings but I was a little confused as I thought it didn't have anything like speed step, but it was just my ignorance....again.
Thanks for the tip. ! Is there any way to track possible underruns by using a code in a terminal ? So far, I haven't heard any deficiencies and in fact, it sounds very good indeed.
Totally Chuffed !
Of course Ubuntu is resampling, all OSes do that as far as I know, unless they are told not to =)
Pulseaudio which is the default however does not resample if source material sampling rate is the same as the output sampling rate defined in daemon.conf. So if 99.9 % of your library is the same sampling frequency, probably 44100 hz and you set that in daemon.conf it will never resample those files.
If you have a good enough algorithm for resampling its basically whatever though. The problem with resampling is when it's done with crappy quality and not and not resampling itself, as far as I know practically every modern dac uses resampling anyway.
If you absolutely doesn't want to resample in Ubuntu it's possible but not with rhythmbox since it doesn't allow you to control the output. If you want to do that then you are better off with mpd, where you can specify to output directly to the hardware.
Doing this as explained earlier by phofman prevents you from playing multiple sounds at the same time but if it's a primarily music PC then that of course isn't really a problem. I did this myself until pulseaudio became good enough to stop all crackling and such.
Footnote: if your using pulseaudio and want to check if you are resampling you can test this by setting "resample-method = src-sinc-best-quality" and then check for cpu usage when listening, if music is played without pulseaudio eating 20-50 % cpu then no resampling is done =)
If your kernel is compiled with option CONFIG_SND_PCM_XRUN_DEBUG, you can monitor xruns in /proc/asound , see XRUN Debug - AlsaProject . However, I doubt distribution kernels have it enabled, at least mine in ubuntu does not.
Xruns are loud cracks, often easy to detect audibly.
Rhythmbox uses gstreamer, sink called musicaudiosink. Unfortunately configuration of this sink is not supported in gstreamer-properties (unlike audiosink) , the "multimedia configuration" screen of ubuntu. You can change the musicaudiosink value to alsasink and specify name of the actual alsa device using graphical gconfd-2 or text gconftool-2. For parameters see alsasink .
BUT this is global setting for all gstreamer applications which sucks. I am afraid the gstreamer library cannot be configured by environment variables, thus allowing individual settings for each running application. Perhaps running proper gconftool-2 commands prior to each application would do but it is certainly not documented or recommended. I do not like the gstreamer rigidity.
Hi folks.
Just to let you know.
96k & 44k1 tracks played with Clementine via pulseaudio sink:
Clementine seems to play the native rates.
Issue: I need to manually switch samplerates on the HDSP9632 card itself.
A HDSP driver issue. Under Windows the driver switches automatically samplerates.
Just to let you know.
96k & 44k1 tracks played with Clementine via pulseaudio sink:
Code:
me@pc1:/proc/asound/card0/pcm0p/sub0$ cat hw_params
access: MMAP_NONINTERLEAVED
format: S32_LE
subformat: STD
channels: 8
rate: 96000 (96000/1)
period_size: 4096
buffer_size: 8192
me@pc1:/proc/asound/card0/pcm0p/sub0$ cat hw_params
access: MMAP_NONINTERLEAVED
format: S32_LE
subformat: STD
channels: 12
rate: 44100 (44100/1)
period_size: 2048
buffer_size: 4096Clementine seems to play the native rates.
Issue: I need to manually switch samplerates on the HDSP9632 card itself.
A HDSP driver issue.
Under Windows the driver switches automatically samplerates.
Last edited:
Your card supports 32 bits only, the hw_params does not reveal anything about the playback chain bit width.
Linux/sound/pci/rme9652/hdsp.c - Linux Cross Reference - Free Electrons
What I find interesting it that pulseaudio would switch sample rates when fed various tracks. I always thought pulseaudio would run at fixed configured sample rate. Are you really sure the audio sink was pulseaudio?
You are right.
I had alsasink and plughw:0,0 configured.
Just verified it.
neither pulsaudiosink nor alsasink hw:0,0 wouldn`t work on both rates.
Actually hw:0,0 is not working at all.
I'm more than happy though that at least the alsasink plug setting works.
Strange though that I do not get hw going. Perhaps that's prevented by pulseaudio, which stays in control about everything..
That's because your card supports 32 bits only. Apparently gstreamer does not adjust its output to the card hw parameters. I find this approach OK, that is why we have the automatic conversion plugin "plug". You gain nothing positive by avoiding this plugin, only a very real chance of troubles as experienced by you and others multiple times.
Ok. It's a gstreamer issue.
Let's skip SQ discussions of hw vs plug for now
I just disabled pulseaudio:
autospawn = no
in /etc/pulse/client.conf
and took pulse out from "Startup Applications".
Seems to work without removing pulse completely .
Ok. It's a gstreamer issue.
Let's skip SQ discussions of hw vs plug for now
Well, I would not call it gstreamer issue, but issue of your particular setup. By default the sound system uses either pulseaudio, or the "default" alsa-lib chain for systems without pulseaudio. Both options provide the automatic format conversion of some form. You have setup your general-use system (gstreamer) in a way alsa is not supposed to be used (i.e. no automatic format conversion within the chain). It is no surprise you are hitting problems.
didn't knew it.
DeaDBeeF - Ultimate Music Player For GNU/Linux
Just tried... nice one!
Although I think the new banshee is way more complete. With "banshee-extension-lastfmfingerprint" plugin being the single greatest feature ever...
Last edited:
Open-source (asynchronous) USB 2 interface: Audio Widget
Talkin' about Linux Audio, keep an eye on this project: http://www.diyaudio.com/forums/digital-source/185761-open-source-usb-interface-audio-widget.html
That looks like the answer to all of our computer-audio interface problems... and is fully open-source!
Talkin' about Linux Audio, keep an eye on this project: http://www.diyaudio.com/forums/digital-source/185761-open-source-usb-interface-audio-widget.html
That looks like the answer to all of our computer-audio interface problems... and is fully open-source!
Last edited:
Hi folks.
I just wanted to let you know that I ran a little study about different CD drives and extraction tools
and associated rip results.
As you'll read I got inspired to do so by an article in the latest issue of german audio magazine called "Stereo".
Just follow below signature, if that topic is of any interest for you.
The Linux aspect of it:
1. cdparanoia delivered 100% identical results in comparison to EAC/dbPoweramp/Foobar/(iTunes)
2. To do the comparison and analysis I used 100% Linux tools
Cheers
I just wanted to let you know that I ran a little study about different CD drives and extraction tools
and associated rip results.
As you'll read I got inspired to do so by an article in the latest issue of german audio magazine called "Stereo".
Just follow below signature, if that topic is of any interest for you.
The Linux aspect of it:
1. cdparanoia delivered 100% identical results in comparison to EAC/dbPoweramp/Foobar/(iTunes)
2. To do the comparison and analysis I used 100% Linux tools
Cheers
Last edited:
/this is a bit off topic, bit not. anyways i never realy had luck with linux.
ubuntu /fedora distro, both freezed while installing. hardware wise i em okay, ms stuff runs fine, pc is working properly. Gentoo failed to recognise my lan card, and my uadio chip, WEEKS of trial and forum reading, irc chatting led me to forget it. DSL linux did run, with minor issues. BTW, i use DSL quite often as a tool for repairs. Even if linux sounds good, i just simply found it way to demanding to play with it for .. who ever know how long just to get some sound out of it.
but is an intresting thread, was thinking hardware influences the sound quality more than the playback software.
ubuntu /fedora distro, both freezed while installing. hardware wise i em okay, ms stuff runs fine, pc is working properly. Gentoo failed to recognise my lan card, and my uadio chip, WEEKS of trial and forum reading, irc chatting led me to forget it. DSL linux did run, with minor issues. BTW, i use DSL quite often as a tool for repairs. Even if linux sounds good, i just simply found it way to demanding to play with it for .. who ever know how long just to get some sound out of it.
but is an intresting thread, was thinking hardware influences the sound quality more than the playback software.
Let's put is this way. If we take conversion of data, such as digital volume control and sample rate conversion, out of equation - everything regarding soundquality relates directly to hardware issues.
Software indirectly affects those HW related issues.
Inefficient SW or OSes can cause e.g. higher and/or strong varying loads which turns e.g. into higher noise or jitter/timing variations.
IMO the key issue is that the vast majority of soundinterfaces is not able to cope with those challenges. Even after years of knowing about the issue manufacturers are not able to address it properly.
For those fighting nvidia HDMI and alsa:
ftp://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gpu-hdmi-audio.html
ftp://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gpu-hdmi-audio.html
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.