uaudio usb sound card verified working on NetBSD.

anarchosax

I need a usb sound card that is verified to work on NetBSD. I have a computer where the sound card isn’t compatible with NetBSD and I need a working solution. I have tried purchasing a usb sound card that should work with NetBSD, as it is the correct device class, but it doesn’t.

Can anyone please tell me what they have found to work (and are using on a regular basis), so that I don’t have to throw more money out of the window?

rvp

anarchosax I have tried purchasing a usb sound card that should work with NetBSD, as it is the correct device class, but it doesn’t.

Can you please post a dmesg output as follows:

Power off; boot with the USB unplugged.
After the system boots, plug-in the USB card.

Also, the output of:

usbdevs -v

It could be that your device wasn't recognized by the correct driver (because the specific USB ID isn't recognized) and was therefore claimed by some generic driver--which results in flaky behaviour. This happened to me not 2 days ago with my USB-ethernet adapter. The fix was pretty simple.

anarchosax

rvp Thanks for the reply. As requested. Here is the end of dmesg:

[   155.961969] uaudio0 at uhub5 port 1 configuration 1 interface 0
[   155.961969] uaudio0: AudioQuest (0x21b4) AudioQuest DragonFly Black v1.5 (0x0083), rev 2.00/1.08, addr 2
[   155.971969] uaudio0: autoconfiguration error: ignored audio interface with 2 endpoints
[   155.971969] uaudio0: autoconfiguration error: no usable endpoint found
[   155.971969] uaudio0: autoconfiguration error: audio descriptors make no sense, error=4
[   155.971969] uhidev5 at uhub5 port 1 configuration 1 interface 2
[   155.971969] uhidev5: AudioQuest (0x21b4) AudioQuest DragonFly Black v1.5 (0x0083), rev 2.00/1.08, addr 2, iclass 3/0
[   165.971891] uhid9 at uhidev5: input=0, output=0, feature=64

# usbdevs -v
Controller /dev/usb0:
addr 0: super speed+, self powered, config 1, xHCI root hub(0x0000), NetBSD(0x0000), rev 1.00(0x0100)
 port 1 disabled
 port 2 disabled
 port 3 disabled
 port 4 disabled
Controller /dev/usb1:
addr 0: high speed, self powered, config 1, xHCI root hub(0x0000), NetBSD(0x0000), rev 1.00(0x0100)
 port 1 powered
 port 2 powered
 port 3 powered
 port 4 powered
 port 5 addr 1: full speed, self powered, config 1, Bluetooth Radio(0xc123), Realtek(0x1358), rev 0.00(0x0000), serial 00e04c000001
 port 6 powered
 port 7 powered
 port 8 powered
 port 9 powered
 port 10 powered
Controller /dev/usb2:
addr 0: super speed+, self powered, config 1, xHCI root hub(0x0000), NetBSD(0x0000), rev 1.00(0x0100)
 port 1 disabled
 port 2 disabled
Controller /dev/usb3:
addr 0: high speed, self powered, config 1, xHCI root hub(0x0000), NetBSD(0x0000), rev 1.00(0x0100)
 port 1 addr 1: low speed, power 100 mA, config 1, Wired Keyboard 600(0x07f8), Microsoft(0x045e), rev 3.00(0x0300)
 port 2 addr 2: high speed, self powered, config 1, 802.11n NIC(0x0109), Realtek(0x2357), rev 2.00(0x0200), serial 00e04c000001
 port 3 powered
 port 4 powered
Controller /dev/usb4:
addr 0: super speed+, self powered, config 1, xHCI root hub(0x0000), NetBSD(0x0000), rev 1.00(0x0100)
 port 1 disabled
 port 2 disabled
Controller /dev/usb5:
addr 0: high speed, self powered, config 1, xHCI root hub(0x0000), NetBSD(0x0000), rev 1.00(0x0100)
 port 1 addr 2: full speed, power 40 mA, config 1, AudioQuest DragonFly Black v1.5(0x0083), AudioQuest(0x21b4), rev 1.08(0x0108), serial AQDFBL0100137256
 port 2 addr 1: full speed, power 98 mA, config 1, USB Receiver(0xc52b), Logitech(0x046d), rev 24.07(0x2407)
 port 3 powered
 port 4 powered

rvp

anarchosax

[   155.971969] uaudio0: autoconfiguration error: ignored audio interface with 2 endpoints
[   155.971969] uaudio0: autoconfiguration error: no usable endpoint found
[   155.971969] uaudio0: autoconfiguration error: audio descriptors make no sense, error=4

Hmm. This may already be working in -HEAD. Can you move the 10.0 kernel, modules and other bits out of the way and try a -HEAD kernel?

# Move 10.0-RELEASE bits out of the way.
#
mv /netbsd /netbsd.10
mv /etc/mtree/set.modules /etc/mtree/set.modules.10
mv /etc/mtree/set.gpufw /etc/mtree/set.gpufw.10
mv /libdata/firmware /libdata/firmware.10
mv /usr/libdata/firmware /usr/libdata/firmware.10

# Extract 10.99.10 (-HEAD) kernel and related bits.
#
tar -C/ -xf kern-GENERIC.tar.xz
tar -C/ -xf modules.tar.xz
tar -C/ -xf gpufw.tar.xz

If that works, but, you want to go back to 10.0, put everything back, then recompile a 10.0 kernel with this line uncommented.

anarchosax

rvp Thanks for the feedback, but I don’t have any idea what you are referring to. I am just a desktop user trying to get things working, and over time learn more about the system.

rvp

anarchosax I don’t have any idea what you are referring to.

Just follow the instructions in prev. post (now with comments!).

Kernel compilation steps I've already given.

anarchosax over time learn more about the system.

Now's your chance! Carpe Diem!

anarchosax

rvp I will take a look at the instructions again, when I have some more time. Despite appreciating your help, my important take away from this is that NetBSD users are being seriously let down. Users are relying on lists of hardware that is “confirmed” to work (as in the case of my other sound card) or purchase a card that is in the same class as what is recommended, yet neither works out of the box. The best case scenario is that users have to compile their own kernel, and when they express the slightest doubt, are told to give it the old college try? We deserve better.

I and many other users are willing to put an effort into learning about NetBSD, but that doesn’t mean that we should have to jump off at the deep end to learn to swim, nor is waiting three more years for the next version of NetBSD. Compiling lists of working hardware goes only so far, if the first thing needed after an install is to compile a kernel.

anarchosax

rvp It seems to me as a user, that the NetBSD fundamentals are sound, but hardware support for particularly WiFi and sound cards (internal as well as USB external) is slow.

Perhaps it is time for NetBSD users to wake up and realize that it is cheaper to try and finance bounties in these areas, rather than everyone ending up with hardware they can’t use… It would also draw new users to NetBSD.

rvp

anarchosax hardware that is “confirmed” to work (as in the case of my other sound card)

The specs. for the old (introduced 2013) Audigy Fx states the chipset used is a Realtek ALC898 but, yours is an ALC899. Marketing names can be tricky. In this case, the PCI ID is also the same, but the chipset is different.

BTW, Creative also says, in the Audigy Fx User Manual, that if you have an onboard or another card present, you should disable that first. Can you try that?

anarchosax [...] but that doesn’t mean that we should have to jump off at the deep end

More like paddling in the kiddie pool, in this instance.

anarchosax the first thing needed after an install is to compile a kernel.

Can't be helped: The complete set of people with commit access to NetBSD has precisely 284 names. These include all developers: kernel/lib/docs/www/pkgsrc/retired/dead/occasionally active people. The number who've actually worked on audio stuff is probably just 2 or 3. How much audio HW would they have access to?

kc9udx

One of the reasons I like NetBSD is because it's "slow to adapt". If I wanted latest, greatest, and so buggy I have to update every day and spend all my time figuring it out, I'd go with Arch. I don't use floppy disks on platforms where I'll use NetBSD. But I'm very happy that I could if I would.

I thought I posted recently about USB "sound cards" that I found to sorta work, but I can't find it at the moment.

anarchosax

kc9udx Slow to adapt is OK as a principle, but if it isn’t possible to find anything currently on the market that works (including eBay) or isn’t confirmed as working and actually works, then that is too slow. I am not looking for the latest and greatest either. In fact, I think that an operating system like NetBSD is far more environmentally correct, as it supports old hardware galore. Despite some of that old hardware being less energy efficient…

Coordination and bounties could avoid users purchasing dongles and what not that don’t work with NetBSD, and increase user and developer satisfaction.

kc9udx

There is hardware available that works. Finding it is the problem.

anarchosax

delete

anarchosax

Interesting problem in the context of the above. I needed to get the computer going for music practice and didn’t have time to try working with the kernel at the moment. I tried installing a number of Linux distros. All said that my built in audio card is disabled and I haven’t been successful in getting it to work again. I am not playing the blame game, but I am wondering if either NetBSD or the usb sound card did this, and what I can do to get it working again…

rvp

anarchosax All said that my built in audio card is disabled and I haven’t been successful in getting it to work again. I am not playing the blame game, but I am wondering if either NetBSD or the usb sound card did this, and what I can do to get it working again…

Don't think NetBSD has that kind of super-power. Try removing the Audigy.

anarchosax

rvp I don’t think so either, but I am almost certain now that the AudioQuest DragonFly Black USB sound card does. I don’t know how it does it, but that would get the sound card to work under both NetBSD and Linux, despite not being supported, and it works under Linux out of the box. Obviously, being class 1.0 compliant has something to to with it as well, but with Windows and Mac, a program is required to switch between sound cards. Maybe it only affects my system this way, I don’t know yet.

rvp

anarchosax I'm afraid you've lost me now: so the AudioQuest USB card was the culprit?

As for getting that to work, see my post #4. You can try the latest -HEAD kernel now, or compile the 10.0-RELEASE kernel with that 1-line change.

anarchosax Obviously, being class 1.0 compliant has something to to with it as well.

Sometimes generic USB class drivers won't do the trick. See PR #58250 which I filed recently. The generic ethernet driver cdce(4) would make the adapter work only in something like 1 out of 10 reboots.

anarchosax

rvp Yes. Actually, (the simplest explanation possibly being the correct explanation) something got overloaded, as switching sound cards wasn’t possible (as with Win and Mac systems)...

rvp

anarchosax something got overloaded, as switching sound cards wasn’t possible

In that case, just try the Audigy again on NetBSD after you pull out any HW or disable in BIOS anything not needed for an audiocfg test of the card. NetBSD's device power management is pretty pathetic.