Has anyone tried a CX31993 USB DAC with FreeBSD?

Not an Apple developer so this might be stupid question, but iPad apps cannot generically access USB, only through class-compliant abstraction?

Yes. The specific issue is that Apple doesn't allow you to load drivers on iOS/iPadOS/TvOS.

This could be used as a good marketing gizmo for FreeBSD audio peripherals. "If it works on iPad, it works for us".

That is the case. But you can't rule out that there are devices which were made to work on iOS by try-n-error and aren't quite clicking with FreeBSD. Never seen one, though.
 
I would say specific issue would be lack of libusb since it looks like it could've ran on jailbroken devices at least 5 years ago judging by posts.

So yeah the general issue is Apple doesn't allow drivers, kernel or userland of this type which forces apps to use class compliant access to USB audio hardware. Now there may be tricks possible especially through umidi and sysex messages that hardware and iPad app understand, and our ecosystem doesn't.

I don't think this is a problem tho, that communication is plain and can be sniffed and reproduced, if the device really needs to be initialized by proprietary protocol running over the wire in standard format.

Therefore I will be using this 'iPad compatibility' in advocating FreeBSD audio for sure :)

Sound Devices' MixPre 1 is such an example that is registering as class compliant but useless since by default nothing is routed.

Could 'replay attack' be used to initiate the device maybe?
 
Could 'replay attack' be used to initiate the device maybe?

Yes, I had the same thought. I have a full USB trace of WIndows XP initializing the MixPre 1 (they never even released software for 64 bit Windows).

But it had too much hair for a quick hack to make it work. For starters it seemed to have a complicated handshake to download a firmware blob.
 
Yeah such things can get elaborate. I guess if there is a will there is a way, and that could start happening for any contemporary devices if FreeBSD audio starts gaining users on grounds of its merit. Also having any kind of Linux code for said device could help - even inside a proprietary application.
 
It's kind of a shame that setting hw.snd.default_auto to 1 didn't appear to work for me. It's supposed to assign hw.snd.default_unit to the most recently plugged in device, but it didn't seem to do anything, and I had to assign it manually each time I plugged one in. Is that any kind of known issue? it's only a small thing but it would be nice if it was automatic.
 
For USB sound devices I use a small script that sets up all sysctls and the default device and gets called by devd.

E.g.:
/usr/local/etc/devd/smsl.conf
Code:
notify 100 {
    match "system"        "USB";
    match "subsystem"    "INTERFACE";
    match "type"        "ATTACH";

    match "vendor"        "0x152a";
    match "product"        "0x85dd";

    action "/usr/local/etc/devd/smsl_setsysctls.sh";
};

notify 100 {
    match "system"        "USB";
    match "subsystem"    "INTERFACE";
    match "type"        "DETACH";

    match "vendor"        "0x152a";
    match "product"        "0x85dd";

    action "/usr/local/etc/devd/defaultpcm.sh";
};
/usr/local/etc/devd/smsl_setsysctls.sh
Code:
#!/bin/sh

uaudionum=`sysctl dev.uaudio | grep "SMSL USB AUDIO" | cut -d'.' -f3`

pcmnum=`sysctl dev.pcm | grep uaudio$uaudionum | cut -d'.' -f3`

#sysctl dev.pcm.$pcmnum.play.vchanformat=s32le:2.0
#sysctl dev.pcm.$pcmnum.play.vchanrate=192000
sysctl dev.pcm.$pcmnum.play.vchanmode=adaptive
# bitperfect requires vchans to be disabled to work properly
sysctl dev.pcm.$pcmnum.play.vchans=0
sysctl dev.pcm.$pcmnum.bitperfect=1

hw.snd.feeder_rate_quality=4

mixer -d $pcmnum
mixer -f /dev/mixer$pcmnum vol=1 pcm=0.9

sysctl hw.snd.default_unit=$pcmnum

the 'defaultpcm.sh' simply sets hw.snd.default_unit to the onboard sound just to get everything back to a 'known state'. I don't use the onboard device at all, and the USB DAC/AMP is always connected, so I could as well just omit the DETACH rule.
 
I've just been trying out the JM20 on a T490 thinkpad. It sounds much better than the T490's motherboard DAC, which is a realtek ALC257. In fact the X201/X220 conexant chip sounds quite a lot better than the T490 mobo chip too, which is kind of surprising. Anyway the JM20 is a good upgrade for the T490, especially at the price I paid.

Just going by the particular chip might not be the whole story either, the circuit implementation that has been used also matters. The classic example was the NAD3020 which used bog-standard 2N3055 power transistors yet got real hifi performance out of them. The realtek chip.in my mini pc sounds excellent, for example. All you can really do is listen to devices and find one you like.
 
Back
Top