Linux Audio the way to go!?

soundcheck · 2014-01-16 11:10 am

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

soundcheck · 2014-01-16 11:30 am

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

phofman · 2014-01-16 11:36 am

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/

cmiu007 · 2014-01-16 8:03 pm

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
};

phofman · 2014-01-16 11:01 pm

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.

cmiu007 · 2014-01-18 2:41 pm

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.

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.

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.

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

GILVANDO · 2014-01-21 12:17 am

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?

cmiu007 · 2014-01-21 11:25 am

GILVANDO said:
Now I will study how to automate the conversation file 44.1 kHz to 48 kHz. What do you suggest? Dmix?

you can try this if you don;t want to modify the source file

Using libsoxr-lsr in Alsa Rate Plugin with LD_PRELOAD | Blog IVITERA a.s.

MrSlim · 2014-01-22 4:23 pm

GILVANDO said:
Now I will study how to automate the conversation file 44.1 kHz to 48 kHz. What do you suggest? Dmix?

Why do you want to convert ?

GILVANDO · 2014-01-22 5:58 pm

Simplify the operation. On hardaware that I am using (EMU-1820M) the software for recording on linux worked better at 48 kHz. So to watch Youtube and use some other player, I have to go back to 44.1 kHz through Emutrix or Alsamixer.

soundcheck · 2014-01-29 9:54 am

Hi folks.

Gotta question. A friend of mine has a NAD M51.

I can't get it to work under Linux. Modules are loaded, the device is registered, but the stream wont start.

I run a 3.12 kernel.

Now the interesting thing is that he hooked up the M51 to a Nexus 7 (KitKat 4.4 -- kernel 3.10?) and immediately started playback. :headbash:

What am I missing ?? Any hints are appreciated.

Cheers

phofman · 2014-01-29 10:18 am

linux:diverse:nad_m51 [Kristoffer] ?

soundcheck · 2014-01-29 11:22 am

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;
 		}
 	}

Oystein · 2014-01-29 3:09 pm

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.

GILVANDO · 2014-02-01 7:36 pm

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?

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.

phofman · 2014-02-01 8:43 pm

GILVANDO said:
Simplify the operation. On hardaware that I am using (EMU-1820M) the software for recording on linux worked better at 48 kHz.

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.

GILVANDO · 2014-02-01 11:45 pm

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.

phofman · 2014-02-01 11:54 pm

Well, I am not asking why linux but why you have to resample when your library contains tracks with various samplerates. Unless you are doing recording or audio work, low-latency provided by jack (running by principle at a single samplerate) is not needed.

GILVANDO · 2014-02-02 10:59 am

To Phofman

You are correct in their assertions. I'm using Linux for both listening to audio files as well as for recordings (Ardour and Reaper).

Gobble · 2014-02-03 3:55 am

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.

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

Linux Audio the way to go!?

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member

Member