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.
I guess next time you'll dissect my posts into words.
You obviously don't get the message.

I'll stop it here. I got better things to do.

My apologies. Perhaps my last reply was a bit in bad taste. I did not mean to offend. If I don't have anything Linux audio related to contribute to the thread the I'll stay out of it.

Sincerely,

Nick


P.S. I hope your ALSA updating script fall under the GPL, this way it can used and/or modified to all.
 
MPD Path to Airport Extreme USB Drive (Airdisk)

I've been trying for several days to get my MPD to see my USB drive hooked up to my Airport Express. Here's how I have it so that I can see it in Nautilus:

smb://jclark8@airport-extreme.local/mybook/itunes/aiff

I've searched the boards and Googled all that I can, but I just can't seem to find the answer.

If I test it with:

music_directory ~/Music

And place some test files in my Music directory, it works fine. I just can't seem to hit on the correct path to make it see my airdisk.

Any help is much appreciated!
 
clar2391,

The path you are using ( smb://username@server/remote_path ) is only recognized by desktop applications compiled with libraries supporting these network paths, e.g. Gnome, KDE, perhaps other. Nautilus is an example of such Gnome application.

Most command line programs work only with regular filesystem paths (/home/user/...)

For you the solution is to convert the network path to your filesystem path, i.e. to mount the network drive to your filesystem (similar to mounting (mapping in winspeak ?) a network drive to F: in windows). In this case the mounting tool is called smbmount.

For usage check e.g. HOWTO: Mounting SMB Shares - Ubuntu Forums or How to use smbmount. - LinuxQuestions.org
 
That worked perfectly. Thanks so much.

I have another question. Before I used the ALSA upgrade script listed by Soundcheck, the volume control in MPC or Minion had no effect on the volume...I could set it at 0 or 100 (or anywhere in between) and I always go full volume output. Since the ALSA upgrade, the MPC and Minion volume control really controls the volume. Is there a way to disable this volume control so that I'm sure to get bit-perfect, full volume output?

I've messed with the mixed settings in mpd.conf, but I'm not sure what settings to change.
 
Hi folks.

I finally managed to assemble a new PC. It's based on a HFX Mini case, Asus AT3N7A-I (ION) MBO ( I swapped the aweful 40mm fan with a quiet 120mm type - running inaudible at 7V from a seperate supply at 30°C coretemp).
I am using external fanless PSs from HFX with Pico PS for DC/DC.

The great thing about the HFX case is that - first of all it IMO looks pretty cool. 2nd it is extremely solid made.

An externally hosted image should be here but it was not working when we last tested it.


and 3rd there is so much space and cooling left, I can even build-in my T2021
amps.

Soundcardwise I went for RME HDSP 9632 + analog extension board (2+4 analog out).
Why 9632? I made a pretty good deal at Ebay. The board is kown for its good quality. Works with Xilinx as interface chip ( I hope decoupling from the PC mess is better compared to other cards.)
It is supposed to be one of the best supported professional cards (e.g. there are dedicated control apps available HDSPmixer/HDSPConf ) under Linux. ( phofman: Yes,yes - I know -- you're catching up slowly but surely ;) )

Con: It is PCI only (However - this matches the chosen MBO pretty well) -
perhaps I'll upgrade later.

Of course a PCI-E MBO would have had quite some advantages over PCI.
Especially the option to supply the card with clean external-power seems to be very attractive.
Anyhow -- one step at a time. First I like to find out the potential of that solution.


Currently I run the OS from an USB stick. I'll switch to an eSata-stick soon.

Back to the HDSP 9632 challenge:

I'd appreciate some hints related to the RME HDSP 9632 setup:

So far I managed to get it going. (after the usual hours of internet research.)

I am still lacking knowledge resp. basic understanding about:

1. amixer settings for volume control and routing to avoid HDSPmixer (to be able to run headless.)
It seems that just HDSPconf reflects all offered amixer settings.
HDSPmixer controls seem to be missing on the Alsa side.
2. routing logic ( perhaps I need to spent some more time wtih HDSPmixer.:confused: )
is there a description of how to use HDSPmixer routing properly?
Somehow the selection of outputs/inputs tags behaves pretty weird.
If I select one the output tags nothing happens inside the pulldown menu.
This must be a user-problem. ;)
If I press master or channel "mute" -- nothing happens. A user problem? :spin:
3. What would be a "neutral setting" in terms of "DSP neutralization".
4. tweak potential (HDSP)
5. is there a udev-rule ( at the moment I load hdsploader (the firmware loader) via rc.local)

Would be nice to hear a "been there, done that" :D (I guess Uli B. is running a similar rig since 5 years or so)

THX
 
It talks via alsa controls. The mixer control is of type HWDEP (based on the driver and hdspmixer code). Try "amixer contents" instead, it should list all control types.

Nope. No difference after changing the controls.

output "amixer contents":

numid=5,iface=HWDEP,name='Mixer'
; type=INTEGER,access=rw------,values=3,min=0,max=65536,step=1
: values=0,0,0


BTW: It seems that the mixer app initializes the card. I have to start it once to get the card playing. Later on I can kill the app and it keeps playing.
 
Last edited:
Nope. No difference after changing the controls.

output "amixer contents":

numid=5,iface=HWDEP,name='Mixer'
; type=INTEGER,access=rw------,values=3,min=0,max=65536,step=1
: values=0,0,0

Check the code at http://git.alsa-project.org/?p=alsa-kmirror.git;a=blob_plain;f=pci/rme9652/hdspm.c method snd_hdspm_get_mixer.

Code:
static int snd_hdspm_get_mixer(struct snd_kcontrol *kcontrol,
			       struct snd_ctl_elem_value *ucontrol)
{
	struct hdspm *hdspm = snd_kcontrol_chip(kcontrol);
	int source;
	int destination;

	source = ucontrol->value.integer.value[0];
	if (source < 0)
		source = 0;
	else if (source >= 2 * HDSPM_MAX_CHANNELS)
		source = 2 * HDSPM_MAX_CHANNELS - 1;

	destination = ucontrol->value.integer.value[1];
	if (destination < 0)
		destination = 0;
	else if (destination >= HDSPM_MAX_CHANNELS)
		destination = HDSPM_MAX_CHANNELS - 1;

	spin_lock_irq(&hdspm->lock);
	if (source >= HDSPM_MAX_CHANNELS)
		ucontrol->value.integer.value[2] =
		    hdspm_read_pb_gain(hdspm, destination,
				       source - HDSPM_MAX_CHANNELS);
	else
		ucontrol->value.integer.value[2] =
		    hdspm_read_in_gain(hdspm, destination, source);

	spin_unlock_irq(&hdspm->lock);

	return 0;
}

The first integer defines source - input channels first, then output channels (thus the upper limit of 2 x HDSPM_MAX_CHANNELS = 2 x 64). The second int defines destination - output channels. And the third int defines the actual gain btw. these channels. if source is input, the gain means input gain, if source is output, the gain means playback gain.

That means if you want to read contents of that control, you have to set first and second integer values, and then read the third one. I am afraid the existing code in amixer cannot do that. It should be relatively feasible to add this functionality to amixer. Setting values should already work - just set the three values (input, output, gain). I do not volunteer since I have no HW to test on and remote testing takes too much amount time as I am not Takashi Iwai :)

BTW: It seems that the mixer app initializes the card. I have to start it once to get the card playing. Later on I can kill the app and it keeps playing.

It is possible, check the code of git.alsa-project.org Git - alsa-tools.git/tree - hdspmixer/ and look for reasonable names. But I would guess that it is the first mixer setup unmuting the mixer after the driver is loaded and the card initialized.
 
Hmmh. I recall having a heavy argument about facing these kind of "challenges" all the time a couple of posts back. I stepped into it again. All things are just half the way done or poorly maintained. :mad:

It is not even funny anymore. You are the one needing this feature. I spent my time finding the info for you. Instead of being willing to do something about it, you start complaining. You are not capable of doing it yourself. You are not willing to pay someone in your area. You even have not asked for this feature on the alsa-devel mailing list. You just act like someone owes you something. Very sad...
 
Last edited:
It is not even funny anymore. You are the one needing this feature. I spent my time finding the info for you. Instead of being willing to do something about it, you start complaining. You are not capable of doing it yourself. You are not willing to pay someone in your area. You even have not asked for this feature on the alsa-devel mailing list. You just act like someone owes you something. Very sad...

Don't take me wrong. It is nothing against you. I really appreciate your support.

Yep -- I do complain about the mess. -- But don't forget that I also actively work on solutions and even communicate these solutions. "Very sad" would be if I would just
complain.

The problem is -- that whole thing becomes a bottomless pit - that's very sad.

For sure I will write the solution down as soon as I have figured it out. As you know I'll share my findings.

I don't think a discussion on the mailing list would deliver any results. From their perspective these are "philosophical" discussions.

Something like that should be brought up and discussed on one of the Linux conferences.

For sure Takashi won't take the ball.
 
I don't think a discussion on the mailing list would deliver any results. From their perspective these are "philosophical" discussions.

Asking on the mailing list about ways to control a specific card mixer from CLI is not a philosophical discussion. Certainly whining about "bottomless pit" will not get you any positive replies from the mailing list subscribers.
 
I have another question. Before I used the ALSA upgrade script listed by Soundcheck, the volume control in MPC or Minion had no effect on the volume...I could set it at 0 or 100 (or anywhere in between) and I always go full volume output. Since the ALSA upgrade, the MPC and Minion volume control really controls the volume. Is there a way to disable this volume control so that I'm sure to get bit-perfect, full volume output?

I've messed with the mixed settings in mpd.conf, but I'm not sure what settings to change.

Sorry for the late reply. My 2 cents guess why the volume control started to work after alsa upgrade: the mpd "turns" an alsa control called "Master Playback Volume". The old alsa driver of your card did not define this control, unlike the new one. Hence the volume control started to work. I guess the easiest would be to configure some non-existing control name in the mixer_control parameter for mixer_type of alsa. Just a guess.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.