Linux audio is the way go, No its not

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Jump to Latest
P

phofman

Member
Joined 2005
jkorten said:
I use Clementine with preference set to:
GStreamer audio engine: Output plugin -> Audio sink (ALSA)
Output device hw:1
Buffer duration:1000ms

(The last item buffer duration I had at the default 4000 and have been decreasing thinking that disk reads would take place more often and things like parking the drive head would occur less frequently - but am still experimenting).
Click to expand...

Buffer duration (if it is buffer time as called in alsa) of 1000 ms or even 4000 ms sounds unrealistically large. Is it really time, milliseconds? Perhaps samples instead?

Players generally have two buffers (plus many others).

Input cache buffers input data for the sample decoding. E.g. parameter -cache of mplayer. This cache determines how often the player accesses your storage.

Output cache - alsa buffer for alsa output, used for transfering data into lower layers. For PCI(e) cards and hw:X output devices this buffer is directly the actual RAM region the card is reading/writing data from/to via Direct Memory Access (DMA). This buffer is split into so called periods. When the soundcard DMA reading pointer crosses boundary of one of the periods, it throws an interrupt, informing the driver. The driver in return informs the application, most typically by waking up the writing thread sleeping on blocking write call to the buffer. The writing thread of the application reads data from the buffer it shares with the decoding part of the player and overwrites the just processed period part of the output buffer with fresh samples.

The buffer contains several periods (at least 2, but players use 8, even 100). The soundcard continues reading the other "loaded, fresh" periods of the buffer while the playback application updates the already processed periods, usually in one run.

Therefore, to be able to assess the timing of the playback chain we have to know the actual output buffer size/time PLUS the period size/time or number of periods in the buffer. Only then can we say how often the writing thread of the playback application is awoken (CPU load) and how long time reserve the playback chain has in the other periods of the buffer loaded with fresh samples for the soundcard.

E.g. mpd uses buffer time of 500 ms master/mpd.git - , split into 4 periods master/mpd.git - . Therefore, a PCI soundcard will throw interrupt every 125ms, very comfortable timing.
 
Last edited:
J

jkorten

Member
Joined 2012
phofman said:
Buffer duration (if it is buffer time as called in alsa) of 1000 ms or even 4000 ms sounds unrealistically large. Is it really time, milliseconds? Perhaps samples instead?

Players generally have two buffers (plus many others).

Input cache buffers input data for the sample decoding. E.g. parameter -cache of mplayer. This cache determines how often the player accesses your storage.

Output cache - alsa buffer for alsa output, used for transfering data into lower layers. For PCI(e) cards and hw:X output devices this buffer is directly the actual RAM region the card is reading/writing data from/to via Direct Memory Access (DMA). This buffer is split into so called periods. When the soundcard DMA reading pointer crosses boundary of one of the periods, it throws an interrupt, informing the driver. The driver in return informs the application, most typically by waking up the writing thread sleeping on blocking write call to the buffer. The writing thread of the application reads data from the buffer it shares with the decoding part of the player and overwrites the just processed period part of the output buffer with fresh samples.

The buffer contains several periods (at least 2, but players use 8, even 100). The soundcard continues reading the other "loaded, fresh" periods of the buffer while the playback application updates the already processed periods, usually in one run.

Therefore, to be able to assess the timing of the playback chain we have to know the actual output buffer size/time PLUS the period size/time or number of periods in the buffer. Only then can we say how often the writing thread of the playback application is awoken (CPU load) and how long time reserve the playback chain has in the other periods of the buffer loaded with fresh samples for the soundcard.

E.g. mpd uses buffer time of 500 ms master/mpd.git - , split into 4 periods master/mpd.git - . Therefore, a PCI soundcard will throw interrupt every 125ms, very comfortable timing.
Click to expand...

I won't second guess the writers of Clementine and assume they are smart enough to know the difference between milliseconds and bytes.

The issue of periods can be addressed directly in jackd (aaakkk!) but I am not aware of any method exposed by Clementine (or MPD for that matter) to instruct ALSA as to how many periods should be buffered. ALSA seems to have a configuration directory, including a subdirectory for USB Audio configuration (/usr/share/alsa/cards/USB-Audio.conf) but where and how to set the periods is not obvious to me (yet).
 
Last edited:
P

phofman

Member
Joined 2005
jkorten said:
I won't second guess the writers of Clementine and assume they are smart enough to know the difference between milliseconds and bytes.
Click to expand...

If it is milliseconds, that figure is most likely capped by buffer_max value provided by the driver gstreamer/gst-plugins-base - 'Base' GStreamer plugins and helper libraries.

Envy24 soundcards support up to 2MBytes (i.e. 1.3 sec for 48k/32bits/8channels) https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/ice1712/ice1724.c#n939, intel hda basically unlimited https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/hda/hda_intel.c#n314 , regular usb audio 1MByte (i.e. 5.2 sec for 48k/16b/2ch) https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/usb/pcm.c#n822


I am not aware of any method exposed by Clementine (or MPD for that matter) to instruct ALSA as to how many periods should be buffered. ALSA seems to have a configuration directory, including a subdirectory for USB Audio configuration (/usr/share/alsa/cards/USB-Audio.conf) but where and how to set the periods is not obvious to me (yet).
Click to expand...

It is important to realize the relationship of jack towards alsa. Jack is an alsa application. Alsa is just a library communicating with alsa kernel drivers. In alsa the buffer and period sizes are configured by the calling application - jackd, mpd, clementine.

MPD - parameters buffer_time, period_time
Clementine - it uses the gstreamer library which reads its setup from gconf:

gstreamer/gst-plugins-base - 'Base' GStreamer plugins and helper libraries

You can change the alsasink parameters (buffer-time, latency-time) by gconf-tool from command line 'Re: Can't play sound on bluetooth headset' - MARC or using the GUI tool gconf-editor.

You can check currently playing stream parameters including samplerate, sample size channels count, ... at any time in file /proc/asound/yourcard/pcm0p/sub0/hwparams

Code: 
pavel@sara:~$ cat /proc/asound/Intel/pcm0p/sub0/hw_params 
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 8192

There is nothing hidden in linux. The availability of complete source code and quality debugging/troubleshooting tools give you absolute power over your PC. As it should be :)
 
Pano

Pano

Administrator
Joined 2004
Paid Member
Interesting to see that this has been taken over by the Penguins. :D Gotta be expected on a DIY site, right?

I still run a cleaned up version of Windows XP as my music server and JRiver as the player. Output is a simple PCI card with Toslink. No glitches, no cracks, no pops. Bit perfect output if I choose to do so (tested). The only unknown is jitter, which I have not measured. May have to try, but don't know what to compare it to.

As for "Optimizing" it seems that all OS need that, to work their best. If they didn't, why all the discussion about this or that Linux distribution or setup? Windoze works OK for audio on most hardware, as long as you don't install most of the junk that comes with it. Knowing how to get a clean install isn't common knowledge, so a guide is worthwhile.
 
Pano

Pano

Administrator
Joined 2004
Paid Member
I suspect it would be just fine for straight ahead playback of wav, flac, ape, mp3, ogg.
But sometimes I use a convolution engine (or other DSP) and was wondering if the little 800Mhz CPU could do it.

From what some of you are saying, maybe not?
 
P

phofman

Member
Joined 2005
It would have been interesting if it included any valuable information, apart of the feelings of the nicely-writing author. Internet is full of "reviews" like that. OK, only some of them about your software.

A DBT test comparing your setup with a regular bit-perfect player (e.g. foobar) with positive result (the listener was able to distinguish the two systems) would be really interesting. But IME that is not going to happen.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Top Bottom