I've built a bunch of DAC interfaces with the excellent SA9227 chip. Works great with Windows, MacOS and Linux (Raspberry Pi). No drivers needed for any of these.
Try as I might though, I can't get it working with my Samsung Galaxy S21 or with an iPhone 12. Any ideas?
The phones simply don't recognise it as an audio interface...
Try as I might though, I can't get it working with my Samsung Galaxy S21 or with an iPhone 12. Any ideas?
The phones simply don't recognise it as an audio interface...
Regarding the SA9227 chip, probably I am not the only dac-focused member wondering if the chip is really more excellent than the more common alternatives. Seems like it would be used in more designs otherwise. If I'm missing something important, would very much appreciate if you could elaborate a little more. Thanks!
I like the chip for a few reasons. It can output I2S, left and right justified data as well as SPDIF, making it really flexible. Copes with most sampling rates up to 384kHz. The main reason though is that it can be used with external clocks (45.1584MHz and 49.152MHz for 44.1/48M based sampling rates) rather rhan relying on software-generated clocks from a single 12M or 27M crystal which most ICs use. No need for PLLs or memory-based reclocking circuits to provide a jitter-free clock. I'm using custom oscillators straight from the manufacturers with 0.05ps phase jitter.
There are probably other chips that will do this, but this seemed to hit the spec I wanted perfectly. It also works seamlessly with most OS versions, I'm just having trouble with mobile phones!
There are probably other chips that will do this, but this seemed to hit the spec I wanted perfectly. It also works seamlessly with most OS versions, I'm just having trouble with mobile phones!
Last edited:
I suspect the reason that its not used more widely is that it needs specialist configuration software to program it up. This isn't widely available. I had to get it under NDA straight from the manufacturer after jumping through a lot of hoops!
@APEXHiFi : Just a basic question regarding the android - is your USB-C-> device cable OTG, IOW does the phone USB port switch to host? Does it power the DAC?
The linux kernel source code released by Samsung for S21 seems to configure the USB audio module to be compiled into the kernel, i.e. it should work with UAC1/2 devices. Kernel 5.4 in that android version is new enough to have complete UAC2 support. SA9227 is pretty standard, no USB driver quirks required, AFAIK. But it's possible samsung actually used a different configuration for your android kernel build.
Also there may be a switch to configure USB-audio priority over the built-in audio, in developer options of android. You might want to check that on your phone.
The linux kernel source code released by Samsung for S21 seems to configure the USB audio module to be compiled into the kernel, i.e. it should work with UAC1/2 devices. Kernel 5.4 in that android version is new enough to have complete UAC2 support. SA9227 is pretty standard, no USB driver quirks required, AFAIK. But it's possible samsung actually used a different configuration for your android kernel build.
Also there may be a switch to configure USB-audio priority over the built-in audio, in developer options of android. You might want to check that on your phone.
Thanks @phofman . Ill take a look at your suggestions.
I've tried a USB-C OTG adapter with a USB-A to USB-B cable to the DAC and a straight USB-C to USB-C cable. Neither worked.
Power to the DAC is provided by the DAC, although I've used isolator ICs between the USB input to the DAC and the rest of the DAC for noise isolation and these take a small amount of power from the USB. Only about 2-3mA though, so no problems with PD implementation or other troublesome USB quirks!
I've tried a USB-C OTG adapter with a USB-A to USB-B cable to the DAC and a straight USB-C to USB-C cable. Neither worked.
Power to the DAC is provided by the DAC, although I've used isolator ICs between the USB input to the DAC and the rest of the DAC for noise isolation and these take a small amount of power from the USB. Only about 2-3mA though, so no problems with PD implementation or other troublesome USB quirks!
And did you verify (e.g. by measuring the incoming usb power voltage at your DAC board) that the phone is switched to host?
That would have been a very obvious and sensible test that any half-competent engineer would have done. No, I didn't! Will give that a try!
Im away for the weekend so Ill give these a try on Monday and let you know the results. Thanks for the suggestions!
I have an SA9227 board that came with a DSP unit. It works with both my Android phone and tablet but has reduced volume. I think the only way to get it to work properly is by using something like USB Audio Player Pro. 99% of what I listen to is Spotify though so I haven't tried it.
Interesting, reduced volume would mean the samples must be modified - some volume control on the android side. Or the android side would have to adjust some USB volume feature provided by the usb-audio device. Maybe the android "media" volume was not at 100%?
IIUC Android does have direct non-mixing path (https://www.audiosciencereview.com/...roid-14-supports-bit-perfect-usb-audio.44675/ and older https://developer.android.com/ndk/guides/audio/aaudio/aaudio#sharing-mode AAUDIO_SHARING_MODE_EXCLUSIVE), but it requires an app to use it (just like on any other OS - wasapi exclusive, alsa hw, etc.) and the exclusive mode can be disabled by vendor customizations.
IIUC Android does have direct non-mixing path (https://www.audiosciencereview.com/...roid-14-supports-bit-perfect-usb-audio.44675/ and older https://developer.android.com/ndk/guides/audio/aaudio/aaudio#sharing-mode AAUDIO_SHARING_MODE_EXCLUSIVE), but it requires an app to use it (just like on any other OS - wasapi exclusive, alsa hw, etc.) and the exclusive mode can be disabled by vendor customizations.
The low volume is a known issue with Android and some USB audio devices. That's why the UAPP app exists. The same thing happens with an Apple headphone adapter.
Hm, do you have any more info? Android uses standard linux kernel alsa USB audio stack, and the user-space layer is open source too. Why should that be the case, and for only some devices?
IIUC UAPP was created when the android linux kernel did not have the newer alsa USB audio support, when only UAC1 was supported by the kernel. So they wrote full UAC2 support in userspace, talking to the USB device directly, using Android USB host APIs (android.hardware.usb).
The user-space audio layer does not have to care what physical technology the audio device uses, the alsa interfaces are standardized for any technology (USB, PCI, AHB, AXI, etc...) It's technically possible android developers hard-coded some specific behavior for some specific transfer technology (why?) but it should be visible in the android source code (if we know what to look for).
IIUC UAPP was created when the android linux kernel did not have the newer alsa USB audio support, when only UAC1 was supported by the kernel. So they wrote full UAC2 support in userspace, talking to the USB device directly, using Android USB host APIs (android.hardware.usb).
The user-space audio layer does not have to care what physical technology the audio device uses, the alsa interfaces are standardized for any technology (USB, PCI, AHB, AXI, etc...) It's technically possible android developers hard-coded some specific behavior for some specific transfer technology (why?) but it should be visible in the android source code (if we know what to look for).
Last edited:
IMO pages 10/11 of https://web.archive.org/web/2013081...st/1057/MarakanaAndroidServicesBlackMagic.pdf are very interesting
Looking at android source code https://cs.android.com/android/plat...404c7da6900658f1b16c42d0da;bpv=1;bpt=1;l=2755 , IIUC:
Android has audio modules - ModulePrimary (non-usb alsa device, typically the SoC I2S/codec), ModuleUsb (basically standard linux alsa device, but only for usb devices), ModuleBluetooth (linux bluez), ...
AudioFlinger (android mixer) checks whether the module supports hardware volume by trying to set it. Only ModuleUsb implements the method setMasterVolume(), the other modules directly return Unsupported. ModuleUsb.setMasterVolume checks whether the actual alsa device has master volume alsa controls and whether these are usable. If so, upon module init it remembers flag AHWD_CAN_SET_MASTER_VOLUME and sends the setVolume requests to the device driver in every volume change request. If the check for master volume of the alsa device fails, AudioFlinger uses internal software volume, like for all the other audio modules (internal, bluetooth, ...)
It is perfectly possible some USB audio devices implement their USB-audio volume control incorrectly which the kernel snd-usb-audio module does not have a fix for via quirk, and hardware volume gets set too low. If a USB-audio device implements the volume properly by UAC standard, the volume is correctly set by hardware. If it does not implement hw volume at all (lots of devices), the software volume control in AudioFlinger is applied.
That would explain the similar behaviour on Apple with same hardware - the apple system will have a similar solution and also expect standard-compliant behavior of the USB-audio devices which report to have the volume feature.
Android has audio modules - ModulePrimary (non-usb alsa device, typically the SoC I2S/codec), ModuleUsb (basically standard linux alsa device, but only for usb devices), ModuleBluetooth (linux bluez), ...
AudioFlinger (android mixer) checks whether the module supports hardware volume by trying to set it. Only ModuleUsb implements the method setMasterVolume(), the other modules directly return Unsupported. ModuleUsb.setMasterVolume checks whether the actual alsa device has master volume alsa controls and whether these are usable. If so, upon module init it remembers flag AHWD_CAN_SET_MASTER_VOLUME and sends the setVolume requests to the device driver in every volume change request. If the check for master volume of the alsa device fails, AudioFlinger uses internal software volume, like for all the other audio modules (internal, bluetooth, ...)
It is perfectly possible some USB audio devices implement their USB-audio volume control incorrectly which the kernel snd-usb-audio module does not have a fix for via quirk, and hardware volume gets set too low. If a USB-audio device implements the volume properly by UAC standard, the volume is correctly set by hardware. If it does not implement hw volume at all (lots of devices), the software volume control in AudioFlinger is applied.
That would explain the similar behaviour on Apple with same hardware - the apple system will have a similar solution and also expect standard-compliant behavior of the USB-audio devices which report to have the volume feature.