Linux Audio the way to go!?

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

soundcheck

Member
Joined 2005
soundcheck-audio.blogspot.com
Yep. If you want to have access to your files on every machine nfs-shares is
the way to go. You can run an MPD deamon on each machine.
You just switch the hostname in Minion. (I actually havn't checked this out yet)

I describe the NFS share setup (about 3 commands) in the Minion setup section of the MPD Wiki.
This is gonna be just a 5 Minute exercise.

You mentioned, there'd be a new brutefir version!?!? I need to check that out.

Cheers
 
Theo404

Theo404

Member
Joined 2008
soundcheck said:
Yep. If you want to have access to your files on every machine nfs-shares is
the way to go. You can run an MPD deamon on each machine.
You just switch the hostname in Minion. (I actually havn't checked this out yet)
Click to expand...

Not 'every' machine. With just two pcs (one linux, one windows) I want to be able to use the magic of brutefir on the linux machine to play the large (and ever expanding) library of music on my windows machine, and control this from windows... doable with MPD, minion and shares?

Originally posted by soundcheck You mentioned, there'd be a new brutefir version!?!? I need to check that out.
Click to expand...

Yep, 1.0k.... just addresses issues with the latest versions of jack and such, but before that there are newer versions than synaptic in ubuntu installs that do more....
 
S

soundcheck

Member
Joined 2005
soundcheck-audio.blogspot.com
phofman said:
What I am looking for (and Theo404 clearly too) is networking the machines on sound-system level, below the actual audio applications.
Click to expand...


Fair enough. For the time being I skipped Jack and Pulseaudio and similar.
MPD is exactly doing what I want.

My goal: Keep it simple and usable.

The tool got accepted quite quickly of my family. This never happend before with any other audio application I came up with.

I am working heavily to get away from a system, which needs a 2 hour introduction to get one song played back. ;)

Talking about integrating video and recording are different stories of course.


Cheers
 
Theo404

Theo404

Member
Joined 2008
Compiling mpd

I'm trying to compile mpd from source as per your guide and have run into an error I cant get around:

src_mpd-jack_plugin.o: In function `mpd_jack_init':
/usr/src/mpd/src/output/jack_plugin.c:207: undefined reference to `jack_set_info_function'
collect2: ld returned 1 exit status
make[1]: *** [src/mpd] Error 1
make[1]: Leaving directory `/usr/src/mpd'
make: *** [all] Error 2

Any hints?
 
S

soundcheck

Member
Joined 2005
soundcheck-audio.blogspot.com
Hi folks.

I am playing a lot with 24/96 material lately. ( there is some great stuff from hdtracks.com available)

I had difficulties to get it going with MPD-pipe-out/ecasound/brutefir.

I'll quickly share my findings, because it seems, that the Linux audio scene is not 100% in sync when it comes to 24bit formats. It took me quite some time and mail-writing again to get
me on top of the mess.

1. MPD pipe-output is S24_LE ( a 32 bit format with 8MSB padded to 0).
2. The usual base data are available in S24_3LE (3 byte format)
3. ecasound and brutefir can not read S24_LE ( really strange), aplay is able to read it
4. ecasound workaround for the time being: run S32_LE and increase volume by 8bits.

1. I am currently checking out what Sox can do in this context.
2. We can also expect a fix on ecasound.
3. A pity - As usual Anders Torger (brutefir) is not responding to mails.
4. MPD won't move either. ( I asked for configurable pipe output formats)

You can look up the ecasound-workaround-config in MPD Wiki example 6 .


Cheers
 
uli.brueggemann

uli.brueggemann

Member
Joined 2006
acourate.com
I'll quickly share my findings, because it seems, that the Linux audio scene is not 100% in sync when it comes to 24bit formats. It took me quite some time and mail-writing again to get me on top of the mess.
Click to expand...

Klaus,

the basic alsa definitions are given in the file pcm.h. The brutefir definitions and connection to alsa are given in the file bfio_alsa.c

You are right, the definitions do not match to each other:

alsa:
/** Signed 24 bit Little Endian using low three bytes in 32-bit word */ SND_PCM_FORMAT_S24_LE,
/** Signed 24 bit Big Endian using low three bytes in 32-bit word */ SND_PCM_FORMAT_S24_BE,
/** Unsigned 24 bit Little Endian using low three bytes in 32-bit word */ SND_PCM_FORMAT_U24_LE,
/** Unsigned 24 bit Big Endian using low three bytes in 32-bit word */ SND_PCM_FORMAT_U24_BE,
/** Signed 32 bit Little Endian */ SND_PCM_FORMAT_S32_LE,
/** Signed 32 bit Big Endian */ SND_PCM_FORMAT_S32_BE,
/** Unsigned 32 bit Little Endian */ SND_PCM_FORMAT_U32_LE,
/** Unsigned 32 bit Big Endian */ SND_PCM_FORMAT_U32_BE,

and

/** Signed 24bit Little Endian in 3bytes format */ SND_PCM_FORMAT_S24_3LE = 32,
/** Signed 24bit Big Endian in 3bytes format */ SND_PCM_FORMAT_S24_3BE,
/** Unsigned 24bit Little Endian in 3bytes format */ SND_PCM_FORMAT_U24_3LE,
/** Unsigned 24bit Big Endian in 3bytes format */ SND_PCM_FORMAT_U24_3BE,
Click to expand...

whereas brutefir uses:

switch (sample_format) {
case BF_SAMPLE_FORMAT_S8:
format = SND_PCM_FORMAT_S8;
*sample_size = 1;
break;
case BF_SAMPLE_FORMAT_S16_LE:
format = SND_PCM_FORMAT_S16_LE;
*sample_size = 2;
break;
case BF_SAMPLE_FORMAT_S16_BE:
format = SND_PCM_FORMAT_S16_BE;
*sample_size = 2;
break;
case BF_SAMPLE_FORMAT_S24_LE:
format = SND_PCM_FORMAT_S24_LE;
*sample_size = 3;
break;
case BF_SAMPLE_FORMAT_S24_BE:
format = SND_PCM_FORMAT_S24_BE;
*sample_size = 3;
break;
case BF_SAMPLE_FORMAT_S16_4LE:
case BF_SAMPLE_FORMAT_S24_4LE:
case BF_SAMPLE_FORMAT_S32_LE:
format = SND_PCM_FORMAT_S32_LE;
*sample_size = 4;
break;
case BF_SAMPLE_FORMAT_S16_4BE:
case BF_SAMPLE_FORMAT_S24_4BE:
case BF_SAMPLE_FORMAT_S32_BE:
format = SND_PCM_FORMAT_S32_BE;
*sample_size = 4;
break;
case BF_SAMPLE_FORMAT_FLOAT_LE:
format = SND_PCM_FORMAT_FLOAT_LE;
*sample_size = 4;
break;
case BF_SAMPLE_FORMAT_FLOAT_BE:
format = SND_PCM_FORMAT_FLOAT_BE;
*sample_size = 4;
break;
case BF_SAMPLE_FORMAT_FLOAT64_LE:
format = SND_PCM_FORMAT_FLOAT64_LE;
*sample_size = 8; break;
case BF_SAMPLE_FORMAT_FLOAT64_BE:
format = SND_PCM_FORMAT_FLOAT64_BE;
*sample_size = 8;
break;
default:
sprintf(errstr, " Unsupported sample format.\n");
return false;
}
Click to expand...

It seems the only solution is to modify bfio_alsa.c and to watch for undesired side effects. :(
 
P

phofman

Member
Joined 2005
S

soundcheck

Member
Joined 2005
soundcheck-audio.blogspot.com
phofman said:

I guess the best solution is filing a brutefir bug report.
Click to expand...

Good idea. :D

I am just a small light, my mails are not being answered by Anders Torger.

Perhaps somebody of you guys give it a try.
I guess he'll listen if he is approached by several people regarding the same subject.

Or we just fix it and send him the patch. ;)

Cheers
 
uli.brueggemann

uli.brueggemann

Member
Joined 2006
acourate.com
It seems to me that jconv may be able to do what brutefir can do and it may be more current. Unfortunately I don't know enough to be sure
Click to expand...

I have used jconv already. A great solution if you need a very low latency (realtime application and minimum phase filters). I could run partitions down to 64 taps with 64k filters without a problem. [Background info: jconv is specially using non-uniform partitioning].

But the configuration is much less comfortable compared to BruteFIR.
Also jack is required whereas I run brutefir without jack.
 
P

phofman

Member
Joined 2005
I would say the new brutefir code does use the 24bit constants incorrectly. pcm_misc.c clearly shows these are 4bytes, whereas brutefir assumes 3 bytes.

I have no "native" 24bit audio, but I would say 24bit stored in 3 bytes is less "special" and more logical than 24bits stored in 4 bytes. Although pcm.h says so :)
 
S

soundcheck

Member
Joined 2005
soundcheck-audio.blogspot.com
uli.brueggemann said:
Klaus likes to use the "special" S24_3LE format and this creates the problem.
Click to expand...

Hi Uli.

I wouldn't call it this way. ;)

There are two formats offered by Alsa. S24_LE and S24_3LE.
Neither brutefir nor ecasound comply to these formats.

S24_3LE is actually the plain 3 byte format ( as used in the music-datafiles) .
In ecasound or brutefir terms it's called S24_LE ( which IMO makes more sense, but who cares about that)

It IMO also makes more sense to call the 4byte format S24_4LE, since this is the special one.


Now somebody could ask:

Why don't you use S24_4LE of brutefir, this should be equal to ALSA S24_LE, which should be in line with the MPD output ?

A very smart question! Isn't it. Yes - I even thought about this - and - I even tried it ;)

Guess what - it does exactly the same as the S32_LE format (8bit attentuation) . My guess: Something could be wrong with the handling of 0 padding (MSB/LSB) inside brutefir.

Uli: I guess that's exactly your point. Somewhere at the input/ouput format conversions something is going wrong.



Cheers
 
uli.brueggemann

uli.brueggemann

Member
Joined 2006
acourate.com
case BF_SAMPLE_FORMAT_S16_4LE:
case BF_SAMPLE_FORMAT_S24_4LE:
case BF_SAMPLE_FORMAT_S32_LE:
format = SND_PCM_FORMAT_S32_LE;
*sample_size = 4;
Click to expand...

Klaus,

as already written before read the brutefir code. :) It clearly shows that SND_PCM_FORMAT_S32_LE is assigned to the format definition for the three cases S16_4LE, S24_4LE and S32_LE.

So there is no difference between interpretation of S24_4LE and SND_PCM_FORMAT_S32_LE
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Top Bottom