SMSL D200 bitperfect mode

Hi

From time to time I try to return to FreeBSD desktop.
This is one of the hiccups while trying out 15-RELEASE.

I've recently aquired SMSL D200 and it works. Unfortunately in bit-perfect mode
the sound is very garbled, altough somewhat resembles the track. Needless to say
it works under Debian 13, just plug and play.

Someone claims it works , but the message is a bit ambiguous.
The device displays right numbers on display while playing tracks with different
sample rates in bit-perfect mode, just like in Debian. Sound seems to be very loud
as I have to turn D200 down from 85 to around 20 (OS mixer doesn't seem to work).
And of course sound is very garbled no matter what loudness is set on D200.

This is what it looks like, while playing 96 kHz track with mpv:

Code:
uaudio0 on uhub3
uaudio0: <SMSL SMSL USB AUDIO, class 239/2, rev 2.00/3.54, addr 2> on usbus1
uaudio0: Play[0]: 384000 Hz, 2 ch, 32-bit S-LE PCM format, 2x4ms buffer. (selected)
uaudio0: Play[0]: 352800 Hz, 2 ch, 32-bit S-LE PCM format, 2x4ms buffer.
uaudio0: Play[0]: 192000 Hz, 2 ch, 32-bit S-LE PCM format, 2x4ms buffer.
uaudio0: Play[0]: 176400 Hz, 2 ch, 32-bit S-LE PCM format, 2x4ms buffer.
uaudio0: Play[0]: 96000 Hz, 2 ch, 32-bit S-LE PCM format, 2x4ms buffer.
uaudio0: Play[0]: 88200 Hz, 2 ch, 32-bit S-LE PCM format, 2x4ms buffer.
uaudio0: Play[0]: 48000 Hz, 2 ch, 32-bit S-LE PCM format, 2x4ms buffer.
uaudio0: Play[0]: 44100 Hz, 2 ch, 32-bit S-LE PCM format, 2x4ms buffer.
uaudio0: No recording.
uaudio0: No MIDI sequencer.
pcm6 on uaudio0
uaudio0: No HID volume keys found.

○ Image  --vid=1  'Cover.jpg' (mjpeg 1500x1500) [external]
● Audio  --aid=1  (flac 2ch 96000 Hz)
File tags:
 Artist: Gadi Lehavi
 Album: Tea for three
 Album_Artist: Ari Hoenig
 Composer: Ari Hoenig
 Date: 2024-12-13
 Genre: Contemporary Jazz
 Title: Hold Up a Minute
 Track: 02
AO: [oss] 96000Hz stereo 2ch float
A: 00:00:09 / 00:06:55 (2%)

dev.pcm.6.feedback_rate: 96000
dev.pcm.6.mode: 3
dev.pcm.6.bitperfect: 1
dev.pcm.6.buffersize: 0
dev.pcm.6.play.vchans: 0
dev.pcm.6.hwvol_mixer: vol
dev.pcm.6.hwvol_step: 5
dev.pcm.6.%iommu:
dev.pcm.6.%parent: uaudio0
dev.pcm.6.%pnpinfo:
dev.pcm.6.%location:
dev.pcm.6.%driver: pcm
dev.pcm.6.%desc: SMSL SMSL USB AUDIO

pcm6: <SMSL SMSL USB AUDIO> on uaudio0 (1p:0v/0r:0v) default
    snddev flags=0xfd<SIMPLEX,SOFTPCMVOL,BUSY,MPSAFE,REGISTERED,BITPERFECT,VPC>
    [dsp6.play.0]: spd 96000, fmt 0x00201000, flags 0x2000010c, 0x00000001, pid 3345 (mpv)
        interrupts 1569, underruns 0, feed 1568, ready 32768
        [b:6144/3072/2|bs:32768/4096/8]
        channel flags=0x2000010c<RUNNING,TRIGGERED,BUSY,BITPERFECT>
        {userland} -> feeder_root(0x00201000) -> {hardware}

If you're curious the other hiccups are:
* Something is accessing HDD's every 10 minutes in inactive (unmounted) zpool, causing
HDD's to spin up. The only cure is to export the zpool after which the disks stay in standby.
* Screen blanks for few seconds and then comes back as a static picture, freezes in other
words. OS stays operational, ssh access possible, ACPI shutdown works etc. It seems to
happen often when playing soundtracks with cover art with mpv. As soon as the cover art
window pops up the screen blanks, then comes back dead. Not always but often. AMD
5500GT APU, standard amdgpu driver installed per handbook.
 
ASR review of the D200
TLDR - they liked it.

Unfortunately I don't have one to test. It would be interesting to try one out. They seem to go for around 300 GBP on amazon, so not hyper-expensive.
 
OP, have you possibly got another machine you can try it with, running freebsd? Perhaps an intel CPU laptop? I am wondering if the problem is something to do with the AMD APU. You could try booting ghostbsd from a live usb stick, just to try out the D200 but without installing the machine. Just a thought. https://www.ghostbsd.org/
 
I wonder how it is even possible for bitperfect mode to not work when mixer mode works. Bitperfect should be the simpler of the two.

Might be worth emailing the code owner about.
 
Garbled/distorted sound in bitperfect mode is an indication of following:
1. the audio file is not exactly 96kHz. that is then hardware does not properly process it.
2. most likely - judging from the same experience that I also have with 2 devices ( FiiO K17 and Fiio M11S ) - in bitperfect mode sound card accepting audio file frequency rate only as multiples of 44100 Hz ( even though it reports as capable of playing 48, 96 and multiples of these ). so that it tries using resampler but it can't because in bitperfect mode the audio stream sent directly to hardware. ( which is good and by design ). however I cannot really tell if it is a limitation of FreeBSD audio stack or hardware quirks.
To verify this observation you can downsample your file to 44100 ( or 88200 for that matter ) with ffmpeg and try playing new audio file. the command for sample conversion with ffmpeg can be easily googled , I do not recall it.
 
To add to this - I really massively dislike all the mess around fancy stuff like high bitrate. most of people is more that ok with 44.1kHz. what is little bit more viable is bit depth. 16bit does not cover all the the dynamic range human ear can handle but 24bit does. so all my flac collection is simply 16bit 44.1kHz or 24 bit 44.1kHz. the latter one is still very uncommon but it should had to be. all the other audiophile-related things are marketing smoke.
 
Garbled sound in bitperfect mode is in 100% of all cases some software mocking with the sampling rate - e.g. resamplers, mixers or crap like pulseaudio that always gets in the way (make sure that junk isn't installed at all; it will spawn regardless of any settings in rc.conf)
OS volume control not working is a sign that bitperfect mode is working - it is supposed to directly send the stream without any modifications to the DAC. You are supposed to control the volume on your (pre-)amp.


I have the smaller brother of this DAC, the DL200 and for "daily driving" I choose to not go with bitperfect mode - simply because there's so much software (primarily browsers) that mocks with the output sampling rate, ruining playback for high-quality sources or simply hogging the output channel and preventing the actual audio player from using it.

This is the script I run via devd to set up the DL200:
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

I use audio/deadbeef (resampler disabled) to listen to my music collection (90% flac and most material from the last ~10-15 years in 24bit and high sampling rates if it was available) and the DAC perfectly switches to the sampling rate of the source material - except if that piece of crap firefox decides to pull it down to 44100 periodically for no reason (killing and restarting it usually fixes that for a few hours).
DeaDBeeF runs in higher priority ( rtprio 9) to prevent hiccups and TBH I can't hear any difference between e.g. 24bit/96000khz in adaptive mode and if it were set as fixed values in bitperfect mode - so I pretty much always stick with 'vchanmode=adaptive' for convenience. From time to time I cross-check by listening in bitperfect mode, but haven't found any difference yet - neither on headphones (Fiio FT1 Pro and some "made in Austria" AKG K702) nor on monitor speakers (only a pair of Edifier R1280DB - I can't listen very loud/often on Speakers, so it's pointless to pour lots of money into them...).


* Something is accessing HDD's every 10 minutes in inactive (unmounted) zpool, causing
HDD's to spin up. The only cure is to export the zpool after which the disks stay in standby.
ZFS is supposed to do its housekeeping periodically in the background, regardless if the datasets are mounted.
Also: Spinup is the single most wear-inducing task for spinning rust and the reason they fail mechanically (also the spinup usually draws more power than you saved in a few minutes of sleep mode). Nowadays HDDs are pretty much only for long-term (cold) storage and large-scale "data hoarding". I haven't put spinning rust in a desktop machine for over 15 years and my servers except for a single backup server also have been flash-only for several years now...
If you absolutely want to put spinning disks in your system *and* put them to sleep, use another filesystem - ZFS is the wrong tool for the job.

* Screen blanks for few seconds and then comes back as a static picture, freezes in other
words. OS stays operational, ssh access possible, ACPI shutdown works etc. It seems to
happen often when playing soundtracks with cover art with mpv. As soon as the cover art
window pops up the screen blanks, then comes back dead. Not always but often. AMD
5500GT APU, standard amdgpu driver installed per handbook.
Never heard about those screen issues except on very early i915 kms driver versions when the drm layer was still experimental. Any chance you are running wayland?
 
pulseaudio that always gets in the way (make sure that junk isn't installed at all; it will spawn regardless of any settings in rc.conf)
PulseAudio is being launched by libpulse.so according to the autospawn setting in /usr/local/etc/pulse/client.conf (which defaults to yes).
 
To add to this - I really massively dislike all the mess around fancy stuff like high bitrate. most of people is more that ok with 44.1kHz. what is little bit more viable is bit depth. 16bit does not cover all the the dynamic range human ear can handle but 24bit does. so all my flac collection is simply 16bit 44.1kHz or 24 bit 44.1kHz. the latter one is still very uncommon but it should had to be. all the other audiophile-related things are marketing smoke.
Nyquist theorem says you don't need more than 44 kHz to cover 20Hz-20kHz, which is 'hi-fi'. My hearing drops off above 13 kHz anyway, that's about my limit, so 44 is more than enough for me. You can check your own hearing out here :-
 
Back
Top