[Packgrog]

I know there's a limited number of Linux users around here, and probably even fewer that also use the M-Audio Transit, but I'll post my issues here just in case there's SOMEONE around here with similar experiences.

Previously, I'd gotten my M-Audio Transit to work on Ubuntu 6.06 LTS by downloading and compiling madfuload-1.2. This works just fine on my Compaq N410c laptop, though the occasional short-outs and deafening static after skipping tracks in Amarok is fairly annoying.

Prior to getting my Monica DAC, I upgraded my work PC from 6.06 to 7.04. Many things work much better on Feisty: the Xine engine finally recognizes my FLAC files, VMWare Server can (and must) be installed from packages rather than source, etc. But I cannot for the life of me get madfuload-1.2 to work on this system. So if I want to play audio from my external USB drive, I have to tote my laptop around, which is kind of tedious. I'd rather just switch workspaces to Amarok on my nice big widescreen LCD, rather than my puny laptop display.

Has anyone else run into this problem? If so, how have you resolved it, or have you not been able to?

-Packgrog

 

[Amarok]

How does it fail? Does it fail to get started at all? If so, it could be a problem with the USB hot plugging/udev system. I had 1 or 2 times where during boot the transit's udev rules code was called before the udev entry existed which made it fail. I was gonna put a loop around that with a usleep() in it, but I haven't had the problem since so I didn't bother.

If madfuload is run during startup are there any errors in /var/log/messages or anywhere else that looks promising (I don't run ubuntu and syslog configs are nowhere near standard.)

I use gentoo and just run emerge --update to... update. This handles merging old config files with new as needed. From the way you talk, it sounds like you did a wholesale upgrade? Did you reinstall madfuload? It modifies some files in /etc. On my system it adds the following file:
/etc/udev/rules.d/42-madfuload.rules which has the firmware download commands. If this got nuked during your upgrade you need to replace it. Reinstalling madfuload should put all of the needed files back.

If this is in place, do an lsusb to see what version transit you have. Find the corresponding line in the ./udev/rules.d/42-madfuload.rules file and try the command as root with the -v option.

From here you'll need to follow any clues produced.
Or follow the instructions of the guy who'll post after me and give you a one line fix ;->

-=A=-

 

[jet87]

I've got Feisty Fawn installed on my desktop, but have been using the Transit on my (WinXP) laptop. I may sit down tonight to see how the Transit and Ubuntu play along. Any resources (other than the almighty Google) I should look at for getting the Transit to work?

 

[raylpc]

just install the madfuload. But you need to do "sudo /etc/init.d/udev restart" to recognize the transit. No ideas why this is necessary in 7.04 now.

 

[Packgrog]

Thanks, raylpc. I'll give that a shot. Strange that it's no longer recognized automatically.

Then again, I always thought it was odd on 6.06 that you had to boot the system WITHOUT the Transit plugged in, then plug in the Transit after boot-up was completed, in order for the system to allow you to switch to it. Otherwise, it would recognize that the Transit was plugged in, but would automatically select the internal sound device and not let you switch. Very annoying.

Thanks again, I'll give this a try.

 

[Packgrog]

Still no go. System recognized it, but no sound. Meh.

 

[psyllium]

Quote:

Originally Posted by Packgrog /img/forum/go_quote.gif Still no go. System recognized it, but no sound. Meh.

Try also 'sudo udevtrigger' which does the same as the udev restart but simply makes it look for new devices.

Once you have done that you might want to give us the output from
'cat /proc/asound/cards'
and
'cat /proc/asound/card1'
assuming that the Transit USB is listed with ID 1 on the last output.

I'm sure you've done this all before there might be something blaringly obvious. I have had the Transit USB working in Feisty before.

 

[psyllium]

Oh you might also want to give the output of:
'amixer -Dhw:1'

Assuming once again the index for the card is 1. (Which would mean the onboard sound is using index 0).

 

[Packgrog]

Well, I managed to get Exaile working. I like it better than Amarok in some ways, largely in that it seems lighter weight. It's missing several of the features I like about Amarok, though, like collection organizing, choice of font size, etc. Not bad, though! And it actually works with the Transit. Quite well, too. Slick!

 

[error401]

This could be the result of ALSA's default all-channels-muted mixer configuration. As far as I remember, Ubuntu sets the mixer to sane defaults when you log in, but if you're connecting the Transit after the fact, ALSA's defaults are probably in place - with all channels disabled. I know this used to be the case with most distros and ALSA in general; I haven't had any problems recently with Ubuntu, but I'm not using a removable sound device either.

Check alsamixer and make sure the outputs aren't muted, players will often modify the pcm output volume, but rarely touch the master, perhaps Exaile is an exception?

 

[Packgrog]

Quote:

Originally Posted by error401 /img/forum/go_quote.gif This could be the result of ALSA's default all-channels-muted mixer configuration. As far as I remember, Ubuntu sets the mixer to sane defaults when you log in, but if you're connecting the Transit after the fact, ALSA's defaults are probably in place - with all channels disabled. I know this used to be the case with most distros and ALSA in general; I haven't had any problems recently with Ubuntu, but I'm not using a removable sound device either. Check alsamixer and make sure the outputs aren't muted, players will often modify the pcm output volume, but rarely touch the master, perhaps Exaile is an exception?

Perhaps it's related to the fact that when I run alsamixer from the commandline, it shows the card being the internal device, even though I selected it as the USB Transit via several other apps. *shrug*

 

[error401]

Quote:

Originally Posted by Packgrog /img/forum/go_quote.gif Perhaps it's related to the fact that when I run alsamixer from the commandline, it shows the card being the internal device, even though I selected it as the USB Transit via several other apps. *shrug*

You can specify which card alsamixer should be addressing with the -c flag, with 0 being the default:
Code:

[left]alsamixer -c 1[/left]

You also may want to look at creating a .asoundrc file which could specify the Transit as your default card for all ALSA applications. I believe the following will accomplish that, but I don't have a system with multiple sound devices available to test with right now (I can try tonight if you like) - replace the card 1 with another id if necessary:
Code:

[left]pcm.!default { type hw card 1 } ctl.!default { type hw card 1 }[/left]

Failing all of that, the drastic solution is simply to prevent the module for your onboard card from loading at bootup, making the Transit the only soundcard the system is aware of. There are several ways to do this, the most elegant being to modify the /etc/hotplug/blacklist file and add the soundcard module to the list. The most drastic being moving the module .ko file out of the kernel tree.

 

[Packgrog]

There we go! Thanks, error401, the defaults in a .asoundrc file did the trick. Had that not worked, I was just going to turn off the on-board sound card via the BIOS. Awesome!

Thanks a ton! Exaile is nice, but it's just not as mature as Amarok. Perhaps I could find the time to learn Python and help add some of the missing functionality...

-Packgrog

 

[Packgrog]

Interesting. The sound is noticeably different when using Amarok vs. Exaile. Both seem do be doing some kind of pre-processing on the volume, as the volume controls on both apps actually effect the volume levels of the audio coming from the optical output of the Transit. This is a little dissapointing, actually, as it sounds sort of fake and distant in Amarok, while sounding harsh in Exaile. I'd be more inclined to believe that Exaile is closer to the original, but I'm not sure.

I may just end up having to use my H120 after all. Volume controls have no effect on the levels coming from the optical out with Rockbox. Perhaps it's the only output I have (at work anyway) that's actually bit-perfect. I'm kind of surprised. Perhaps I should try dropping an email to the writer of the madfu loader.

Sounds great through the H120, though. Man, I'm glad I hung onto this thing for so long.

 

[psyllium]

Quote:

Originally Posted by Packgrog /img/forum/go_quote.gif Interesting. The sound is noticeably different when using Amarok vs. Exaile. Both seem do be doing some kind of pre-processing on the volume, as the volume controls on both apps actually effect the volume levels of the audio coming from the optical output of the Transit. This is a little dissapointing, actually, as it sounds sort of fake and distant in Amarok, while sounding harsh in Exaile. I'd be more inclined to believe that Exaile is closer to the original, but I'm not sure. I may just end up having to use my H120 after all. Volume controls have no effect on the levels coming from the optical out with Rockbox. Perhaps it's the only output I have (at work anyway) that's actually bit-perfect. I'm kind of surprised. Perhaps I should try dropping an email to the writer of the madfu loader. Sounds great through the H120, though. Man, I'm glad I hung onto this thing for so long.

The problem you are having is nothing to do with the firmware loader, and more to do with the sound devices in the operating system. I'd expect the KDE sound engine to be adding a layer on top of the ALSA output - I forget exactly what this layer is called... but if you can bypass it, you might do well.

Have you tried using xmms? I know it's a bit old, but I think it'll give you a bit more control over the output device you are using. If you use the ALSA output plugin and just chuck in hw:1,1 or hw:1,0 whichever it is, it should give you bitperfect output. (Don't quote me though

).