That udev rule probably works on volla 22. I still think the rule should be the full form as in the example, with card0 the KERNEL type (if you see that in “udevadm info -a /dev/snd/by-path/*” output). Xperia 10 iii already has functional udev rule with id “litolagoonqrdsn” and it’s just missing the usbaudio.conf symlink. I’ll add that and I’ll check the other official devices for that.
2 Likes
Ok, I’ll try again on the xperia 10iii. My last tests, I still had to manually
pactl load-module module-udev-detect
EDIT: KERNEL=="<CARD-HERE>" is a bit of an issue if one has more than one card, no?
The reason for that is that /etc/pulse/arm_droid_card_custom.pa is missing the module loading, I’ll add that also, the second line in that file needs to have “load-module module-udev-detect”.
2 Likes
Does some device have more than one internal sound card?
Um, we are talking about EXTERNAL usb audio dacs?
The point of that udev rule is to make the pulseaudio module-udev-detect module ignore the internal sound card so only external cards are handled by the module-udev-detect module.
Ok, yes, of course. But that begs the question, why does one need to specify a ‘class’ device, which you say we have only ‘one’ of, explicitly?
Mostly just for completeness so that there is no chance any external audio card would match the id alone.
Ok, minimal functional changes on the xperial 10iii:
cat /etc/pulse/arm_droid_card_custom.pa
load-module module-droid-card rate=48000 hw_volume=false unload_call_exit=true output_voip_rx=false record_voice_16k=true
load-module module-udev-detect
cat /etc/pulse/xpolicy.conf.d/usbaudio.conf
[device]
type = usbaudio
sink = startswith:"alsa_output."
flags = refresh_always
[device]
type = usbmic
source= startswith:"alsa_input."
flags = refresh_always
That’s sufficient, with some usb-audio dacs. That apple dongle has to have hardware volume set, otherwise it’s silent as @koza observed. Interesting is that the apple dongle is NOT silent under some circumstances (ie. is at 40%). Ah, plug and pray.
EDIT, does sound good 
1 Like
Just a note that /etc/pulse/xpolicy.conf.d/usbaudio.conf should be a symlink to usbaudio.conf.disabled and not a copy of that file.
2 Likes
I need to investigate if there something missing for hardware volume side of that and if hardware volume issue is generic or just specific to that dongle.
A note, I still have ‘‘ATTRS{id}==“mtsndcard”, ENV{PULSE_IGNORE}=“1”’’ udev rule on the xperial 10iii.
i assume the symlink is for ‘upgrade safety’. EDIT: updating the wiki.
I’ve tested 3 dongles. Two worked without issues and on the volla the apple dongle plays, but quietly, on the xperia it’s silent.
That “mtsndcard” rule you have is completely useless on Xperia 10 III which uses “litolagoonqrdsn” and has it already in /lib/udev/rules.d/99-pulseaudio-ignore-builtin-card.rules file..
Ok, thanks. One less rule is better I just wanted to note it was in place.
@robthebold @gabs5807 FP4 and FP5 now have the usbaudio.conf symlink included in repos, in case you used something else than symlink you will have issues updating so if that happens just remove the usbaudio.conf before updating.
4 Likes
I’ve updated the wiki to specify symlinking.
The rule @mal suggested for the vollas also works with otherwise minimal changes: ie. usbaudio.conf.
2 Likes
well yes but you cannot change that on the fly, but changing amount of bits is least impactful, especially if you change it upwards. I even have done it with my code, it’s simple.
That’s why we set default sampling rate to 48000 and set “avoid-resampling”
Wouldn’t say so
Changing amount of bits literally uses next to no power, I’ve done it. it’s literally changing from int16 to int32, or float.
The biggest issue, that you’ve entirely missed, and what resampler does, is from the fact that music is either distributed in multiples of 44.1kHz and 48kHz. Resampling from one to another is always bad, but it’s even worse with bad resampler. That’s where soxr shines. Changing the bits is literally meaningless you can change them upwards and they use next to no processing power. Now changing from 44.1 to 48, now THAT’S where power draw is. If you add avoid-resampling, change default sample rate to 48kHz and play 48kHz resampler is not even used, yes even if amount of bits doesn’t match iirc
1 Like
I work on embedded processors that have ram limits, so I’m a bit sensitive.
In a sense, a lot more music is available at higher bit depths, but the commercial music is generally compressed to 16 bit profiles anyway since the ‘lowest common denominator’ wins. At least, that’s been the norm for the last 20 years. May be changing, though.
Again, I’m a bit stuck in embedded land. Changing bit depth on cpu limited (think 300mHz) devices can make the difference between ‘can produce next sample’ and not. I’m talking about synthesis, now. Floats will require an FPU. I’m not sure yet how relevant it is on a sailfish device, but I’m working on a synth now, so I guess I’ll know soon.
Yes, I was agreeing with this and use sox/r in other contexts (audio sampler).
“a bit”
modern phones can run GTA 5
Sure. And the Mutable instruments code I ported to arduino can run at many times the voice count on my desktop as on my small handhelds. But it runs on both. That’s literally hundreds of synths (or about 100 different synthesis techniques).