Linux Audio the way to go!?

Status
Not open for further replies.
Jump to Latest
#2,221
I see. Thx a lot.

Havn't been playing around a lot with Alsa, since I gave up maintaining the Upgrade script at Ubuntu forums.

Anyhow. That's explains why

Code: 
cat/proc/asound/version

shows

Code: 
Advanced Linux Sound Architecture Driver Version k3.11.0-15-lowlatency

But that's the Ubuntu kernel naming convention. I guess it's hard to tell from that what Alsa version we're talking about.

Is there a changelog summary per kernel revision for Alsa ???


Things are getting more and more complex.

Cheers
 
Last edited:
#2,222
Ok. On the lib/tools etc. side

Code: 
dpkg -l | grep -i alsa

shows

Code: 
ii  alsa-base                              1.0.25+dfsg-0ubuntu4                  
ii  alsa-firmware-loaders             1.0.27-2   
ii  alsa-tools                              1.0.27-2 
ii  alsa-utils                               1.0.27.1-1ubuntu1

That makes things clear from a package perspective.
All clear - except for the driver configurations file status - in alsa-base !?!? Which obviously is still related to 1.0.25. 😕


Cheers
 
Last edited:
#2,223
I do not think the in-kernel alsa drivers are numbered by the alsa numbering scheme any more. It pertains only to user-space utils which continue to be hosted primarily at git.alsa-project.org

A changelog between kernels is available via google search, specifically for alsa:

Code: 
git clone git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git

cd sound

git log v3.12 v3.11 -- sound/
 
#2,224
Hi,
I'm using the following system:
- headless server
- debian live build with persistence on USB stick
- mpd 0.19~git / resampling with libsoxr-lsr
- the music files are mounted via nfs
I'm trying to perform DRC with brutefir but without Jack. After some reading I succeed to have an aost working system.
I have only one problem: when I hit stop brutefir process does not close and I have to manually kill it. Pipe is working fine as I can upsample via SOX without any problem

so when playing:

Code: 
mpd      10461  0.0  0.0  16048   812 ?        S    19:43   0:00 sh -c /usr/local/bin/brutefir -nodefault /var/lib/mpd/.brutefir
mpd      10462  0.3  0.1  47396 14912 ?        S    19:43   0:02 /usr/local/bin/brutefir -nodefault /var/lib/mpd/.brutefir
mpd      10463  3.3  0.1  49832 14888 ?        S    19:43   0:29 /usr/local/bin/brutefir -nodefault /var/lib/mpd/.brutefir
mpd      10464  0.1  0.0  47396  7484 ?        S    19:43   0:01 /usr/local/bin/brutefir -nodefault /var/lib/mpd/.brutefir
after I hit stop

Code: 
mpd      10461  0.0  0.0  16048   812 ?        S    19:43   0:00 sh -c /usr/local/bin/brutefir -nodefault /var/lib/mpd/.brutefir
mpd      10462  0.3  0.1  47396 14912 ?        S    19:43   0:02 /usr/local/bin/brutefir -nodefault /var/lib/mpd/.brutefir
mpd      10463  3.3  0.1  49832 14888 ?        S    19:43   0:30 /usr/local/bin/brutefir -nodefault /var/lib/mpd/.brutefir
mpd      10464  0.1  0.0      0     0 ?        Z    19:43   0:01 [brutefir] <defunct>
mpd log:
Code: 
BruteFIR v1.0m (November 2013)                                (c) Anders Torger

Internal resolution is 64 bit floating point.
SSE2 capability detected -- optimisation enabled.
Creating 4 FFTW plans of size 8192...finished.
Loading 2 coefficient sets...finished.
Realtime priorities are min = 2, usermax = 1, mid = 3 and max = 4.
Estimated CPU clock rate is 3303.274 MHz. CPU count is 4.
Warning: not allowed to set realtime priority. Will run with default priority
  instead, which is less reliable (underflow may occur).
Fixed I/O-delay is 8192 samples
Audio processing starts now
Jan 16 20:00 : player: played "srv/Music/Bombino/(2013) Nomad/04 Imuhar.flac"

Finished!
mpd log after I kill the process by hand

Code: 
Killed
(10830) read from fd 11 failed: Success
Do you have any ideea why is acting this way? Thanks

mpd config:
Code: 
audio_output {
        type            "pipe"
        name            "mpd-brutefir 24/176400 - NODEFAULT"
        command         "/usr/local/bin/brutefir -nodefault /var/lib/mpd/.brutefir" # 2>/dev/null"
        format          "176400:24:2"
        replay_gain_handler "none"
}
brutefir config (only input section):

Code: 
input  "l_in","r_in" {
      device: "file" {path: "/dev/stdin";};  # module and parameters to get audio
      sample: "S24_4LE";   # sample format
      channels: 2/0,1;    # number of open channels / which to use
      delay: 0,0;         # delay in samples for each channel
      maxdelay: -1;       # max delay for variable delays
      subdelay: 0,0;      # subsample delay in 1/100th sample for each channel
      mute: false,false;  # mute active on startup for each channel
};
 
#2,225
1. Did you look at 0003437: "always_on" does not work in pipe mode --> end of track cut off - MantisBT ? It looks as if shutting down brutefir at stop is not the most desired procedure.

2. It looks as if the method bf_exit in bfrun.c does not send SIGTERM to the other threads which should be listed in the icomm->pids array. I would recompile the package with debug symbols, attach the gdb debugger to the reader process/thread (apparently the one with the highest PID), place breakpoint to that function, stop the playback and look around values in that function. Apparently, the guy reporting the bug above did not experience problems with brutefir not exiting properly upon issuing stop in MPD.

Or there is always a way to hack a simple script which checks status of the brutefir processes periodically and if some turns zombie (the Z flag in ps), the script kills its related processes.
 
#2,226
phofman said:
1. Did you look at 0003437: "always_on" does not work in pipe mode --> end of track cut off - MantisBT ? It looks as if shutting down brutefir at stop is not the most desired procedure.
Click to expand...

I stumbled upon it when I search the web for the improper behavior. My problem is that I want to switch before mpd outputs depending of the source file sample rate 44.1 x n or 48 x n or dsd. So in my case is more important that bruterfir exits even if it truncates last seconds of the song.

phofman said:
2. It looks as if the method bf_exit in bfrun.c does not send SIGTERM to the other threads which should be listed in the icomm->pids array. I would recompile the package with debug symbols, attach the gdb debugger to the reader process/thread (apparently the one with the highest PID), place breakpoint to that function, stop the playback and look around values in that function. Apparently, the guy reporting the bug above did not experience problems with brutefir not exiting properly upon issuing stop in MPD.
Click to expand...

It is a little bit over my expertise. 🙁

phofman said:
Or there is always a way to hack a simple script which checks status of the brutefir processes periodically and if some turns zombie (the Z flag in ps), the script kills its related processes.
Click to expand...

I was thinking to this route before I posted the question so here it is the quick and dirty hack

Code: 
watch -n 1 "sh zombie.sh"
zombie sh:

Code: 
ps -eo pid,ppid,state,user,comm | awk 'BEGIN { count=0 } $3 ~ /Z/ { count++; system ("kill -9 " $2) } END { print "\n" count " Zombie(s) were slayed" }'
Thanks for help
 
#2,233
You're the man. Cool. Thx.

I found the section in my 3.12 kernel sources:


If I understand correctly he just won't let the driver die, if a wrong USB descriptor is recognized.
And a wrong descriptor doesn't necessarily mean that a DAC is not gonna be working.

Something like that might increase the compatibility list of USB DACs for Linux. 😉

Interesting though that it works on Android.

Enclosed the adapted patch, if 3.12 kernel sources are to be patched.
I havn't checked it out yet though.


Code: 
-- ./sound/usb/mixer.c.a	2014-01-29 12:10:03.335082952 +0100
+++ ./sound/usb/mixer.c.b	2014-01-29 12:19:14.079038021 +0100
@@ -1341,7 +1341,7 @@ static int parse_audio_feature_unit(stru
 			snd_printk(KERN_ERR "usbaudio: unit %u: "
 				   "invalid UAC_FEATURE_UNIT descriptor\n",
 				   unitid);
-			return -EINVAL;
+			return 0;
 		}
 	} else {
 		struct uac2_feature_unit_descriptor *ftr = _ftr;
@@ -1352,7 +1352,7 @@ static int parse_audio_feature_unit(stru
 			snd_printk(KERN_ERR "usbaudio: unit %u: "
 				   "invalid UAC_FEATURE_UNIT descriptor\n",
 				   unitid);
-			return -EINVAL;
+			return 0;
 		}
 	}
 
#2,234
Although this topic has probably gone sideways from the original question (and not wanting to go through al the pages) I still want to answer anyway.

I am not claiming Linux is better than Windows - I believe both can achieve similar results when set-up properly - but in my situation my BeagleBone Black wit dedicated power and USB supply sounds better than my J.River on uATX mobo with i5-2400.

The greatest beneft for me is the piece of mind having my BBB always powered on, no need for OS/software updates or security issues ... it just always works ... hopfully for many years to come 🙂

FYI:
My system runs Debian Linux with MPD and ncmpc controlled by MPaD.
 
#2,235
News

GILVANDO said:
Re-installed my AV Linux acknowledged EMU-1820M and enabled Alsa recording at 24 bits automatically. The Debian distribution is great. Now I will study how to automate the conversation file 44.1 kHz to 48 kHz. What do you suggest? Dmix?
Click to expand...

I learn and actually use this: JACK Audio Connection Kit to resolve the question. The System is Working at 48 kHz and the Youtube is resampled from 44.1 to 48 kHz.
 
#2,236
GILVANDO said:
Simplify the operation. On hardaware that I am using (EMU-1820M) the software for recording on linux worked better at 48 kHz.
Click to expand...

To go back to your original reason for resampling (which I actually find useless) - what particular recording SW worked better at 48kHz?

Jack does not have any advantage over alsa, unless your need zero-latency chaining applications and low-latency audio work.
 
#2,237
Why LINUX

You said exactly what I'm searching for: Zero-latency chaining applications and low-latency audio work.

Material recorded at 44.1 kHz should preferably be listened to 44.1 kHz. I have some material recorded at 96 kHz and 192 kHz, I collected free on sites specializing in acoustic recordings (orchestras, viololinos, etc.).

On Windows I used Monogram Graph Studio to make direct access to drives the DACs. It is a similar tool on Linux Jack.

For my musical taste the result of drivers Linux is superior to Windows Drivers (on Realtek Chipset, Creative and Emu Cards).

Another factor of great importance is the quality of Headphones used to appreciate and enjoy the recordings.
 
#2,240
phofman said:
. Unless you are doing recording or audio work, low-latency provided by jack (running by principle at a single samplerate) is not needed.
Click to expand...

Absolutely so untrue in my experience.I am running mpd with jack on a linux mint low latency kernel and run only 16/44.1. I use the Ciunas usb-spdif convertor by John Kenny. Without jack in realtime priority 99 and using alsa:hw as the output, the sound is very very ordinary - it does not justify the expense of a $$$ usb/spdif convertor at all.

Sent from my GT-N7000 using Tapatalk
 
Status
Not open for further replies.
Top Bottom