Hello,
Newbie in streaming through Roon and Audirvana here. Can anyone explain why when I listen to a track on Roon, Wiim display it as 16-bit/44.1 kHz with no mention of kbps, but if I play it in Audirvana, Wiim displays 1411 kbps 16- bit/44.1 kHz? If I play the same track in iTunes or Foobar Wiim displays 900 kbps. I assume Roon is giving me the highest playback since Wiim is not reporting any kbps?
Different digital-audio players have different handshakes with your DAC… Don’t presume anything… Just focus on is the tangible sound-quality as perceived through your particular playback component amalgamation and environment scenario… this is what really matters.
*FYI… 1411kbps is the bitrate for a 16bit/44.1kHz signal.
You probably stream using AirPlay from iTunes and the airplay stream is being compressed, which is part of how AirPlay works. Roon and Audirvāna play at cd quality. Foobar is probably using AirPlay as well.
900kbps seems a normal bitrate for a flac file, which is lossless but can still manage to reduce bitrate from nominal 1411kbps down to 900kbps in your case.
Usually when there is Airplay compression you should see around 256kbps.
As far as I know Roons always streams uncompressed pcm, so the WiiM device has probably decided there is no point showing a bitrate. OTOH the WiiM app might clarify things by saying that it is playing a “raw” pcm stream instead of a flac file.
FYI…
Audirvana displays the bit-depth and sample-rate sent to the DAC in the playback window… Generally, the file format that is input, is the file format that is output, unless up-sampling is enabled to modulate PCM to DSD or some bit-depth control is enabled in the ‘Bridge’ settings to limit bit-depth.
Lossless files like FLAC and ALAC get decompressed for playback either in the player or otherwise, in the DAC…
Thank you all for your responses. I am familiar with a lot of these concepts. I was wondering why the playback bitrate was different when played by each player. I am doing this to evaluate Roon and Audirvana, as I want to move away from iTunes at least for audio playback.
I know that Roon and Audirvana try to play using the best output possible, but I am not sure that I have configured the outputs appropriately, I think the kernel output is the cleanest but I have not delved into that yet. I was curious why Roon was showing no bit rate and I think that @GioF71 is correct, that Roon is probably playing an compressed PCM signal, which I assume is the highest bitrate. I wonder why Audirvana is not playing the song uncompressed. It probably has to do with the way I have set things up.
@jmtennapel iTunes was definitely using airplay 2 but foobar was using UPnP. @GioF71 is also correct that the source file was a FLAC (actually an ALAC converted from a FLAC), but it seems the file was not being converted at the endpoint uncompressed. So it seems that foobar and iTunes will transmit a compressed FLAC. Does this get converted by wiim at the endpoint? It seems not, and if I want to hear an uncompressed file, I have to use either Roon or Audirvana. Am I correct?
Yes
Please paste your debug information here…
It is found here: Settings–> My Account–> Help–> Debug info
Please paste a screen-shot of your Audirvana ‘Settings’ screen when playing these files.
When you read the specifications of your DAC it will describe the file formats that it will decode…
From the WiiM Pro and Pro Plus specifications page:
Audio Codec
MP3, AAC, ALAC, APE, FLAC, WAV, WMA, OGG
@Agoldnear, here is the requested information:
Audirvana Studio 2.9.3 (20903)
Windows 11 (22631) x86_64 with 128GB physical RAM
Connected account of : Mario J Salazar
NETWORK
Status: unavailable
Available network interfaces:
Ethernet ({2d02dfeb-3050-4f71-8574-54e5860515de}) is PUBLIC
Windows Defender Firewall status for this instance of Audirvana Studio
Active profile types: all
Private profile:
Firewall: enabled
Inbound: blocked
Outbound: allowed
Notifications: enabled
Public profile:
Firewall: enabled
Inbound: allowed
Outbound: allowed
Notifications: enabled
SIGNAL PROCESSING:
Polarity Inversion:
Globally: OFF
Per track: ON
Effects plugins ACTIVE in offline mode
No plugin active
UPSAMPLING:
r8brain not in use
r8brain filter parameters
Bandwidth = 99.5%
Stop band attenuation 218dB
Phase linear
AUDIO VOLUME:
Max allowed volume: 100
Replay Gain: None
LIBRARY SETTINGS:
Sync list: 1 folders
AUTO: Z:
Library database path: C:\Users\Mario\AppData\Local\Packages\Audirvana.Audirvana-4118-9684-d80dbb7827cd_q3nymrkmej12j\LocalCache\Local\Audirvana\Audirvana\AudirvanaDatabase.sqlite
Local audio files fingerprinting
Tracks with no MBID: 76512
Remote Control server:
Listening on 192.168.50.171 on port 58189
ACTIVE STREAMING SERVICES
APPEARANCE SETTINGS:
UI theme: light
Font size: regular
Language: System language
Show album covers in tracks list: yes
Source list sorted:
Local
My Music
Radios
Podcasts
Streaming
Startup view: Local Library: Tracks
Show local extended in source list: no
Use media keys: yes
Use media keys for volume control: yes
Use legacy Bonjour protocol: no
Number of paired remotes: 1
Remote pairing code required: yes
Screen saver disabled: no
=================== AUDIO DEVICE ========================
Active method: UPnP
Preferred device: [UPnP] WiiM Pro Office Model UID:Linkplay Technology Inc. WiiM Pro-0412 UID:uuid:FF98F09C-ACDE-60F2-FAFE-C257FF98F09C
Selected device:WiiM Pro Office
Manufacturer: Linkplay Technology Inc.
Model name: WiiM Pro-0412
Model UID: Linkplay Technology Inc. WiiM Pro-0412
UID: uuid:FF98F09C-ACDE-60F2-FAFE-C257FF98F09C
UPnP device at http://192.168.50.248:49152/description.xml
6 available sample rates up to 192000Hz
44100
48000
88200
96000
176400
192000
Volume control: Yes
Max volume alert: Enabled
MQA capability
Auto-detect MQA devices: Yes
Not automatically detected, user set to not MQA
DSD capability
Unhandled (PCM conversion) with boost gain of 6dB
Device audio channels
Preferred stereo channels L:0 R:1
Channel bitmap: Ox3, layout:
Channel 0 mapped to 0
Channel 1 mapped to 1
UPnP set capabilities
Maximum PCM frequency set: 192000Hz
Maximum PCM bitdepth set: 24
Not native DSD capable
Avoid RAW PCM streams: No
Unwanted playback stop workaround: No
UPnP / DLNA supported protocols :
http-get::audio/wav:DLNA.ORG_PN=LPCM
http-get::audio/x-wav:DLNA.ORG_PN=LPCM
http-get::audio/mpeg:DLNA.ORG_PN=MP3
http-get::audio/mpeg:DLNA.ORG_PN=MP3X
http-get::audio/x-ms-wma:DLNA.ORG_PN=WMABASE
http-get::audio/x-ms-wma:DLNA.ORG_PN=WMAFULL
http-get::audio/x-ms-wma:DLNA.ORG_PN=WMAPRO
http-get::audio/mpeg:DLNA.ORG_PN=MP2_MPS
http-get::audio/mp3:
http-get::audio/wma:
http-get::audio/mpeg:
http-get::audio/vnd.dlna.adts:DLNA.ORG_PN=AAC_ADTS
http-get::audio/vnd.dlna.adts:DLNA.ORG_PN=AAC_ADTS_320
http-get::audio/m4a:DLNA.ORG_PN=AAC_ISO
http-get::audio/aac:DLNA.ORG_PN=AAC_ISO
http-get::audio/ac3:DLNA.ORG_PN=AC3
http-get::audio/ogg:*
http-get::audio/ape:
http-get::audio/x-ape:
http-get::audio/flac:
DLNA 1.5: Yes
Native Gapless playback: Yes
Universal Gapless playback active: No
Missing events workaround: No
Can play native DSD: No
Volume Control: scalar
Number of channels: 2
Use as stereo device only: No
1 output streams:
Number of active channels: 2, in 1 stream(s)
Channel #0 :Stream 0 channel 0
Channel #1 :Stream 0 channel 1
2 ch Integer PCM 16bit little endian 44.1kHz finite length
2 ch Integer PCM 24bit little endian 44.1kHz finite length
2 ch Integer PCM 16bit little endian 88.2kHz finite length
2 ch Integer PCM 24bit little endian 88.2kHz finite length
2 ch Integer PCM 16bit little endian 176.4kHz finite length
2 ch Integer PCM 24bit little endian 176.4kHz finite length
2 ch Integer PCM 16bit little endian 48kHz finite length
2 ch Integer PCM 24bit little endian 48kHz finite length
2 ch Integer PCM 16bit little endian 96kHz finite length
2 ch Integer PCM 24bit little endian 96kHz finite length
2 ch Integer PCM 16bit little endian 192kHz finite length
2 ch Integer PCM 24bit little endian 192kHz finite length
Current device transportInfo:
CurrentTransportState: STOPPED
CurrentTransportStatus: OK
CurrentSpeed: 1
Current device MediaInfo:
NrTracks: 0
MediaDuration: 00:03:16
CurrentURI: wiimu_airplay
CurrentURIMetadata: <?xml version="1.0" encoding="UTF-8"?>
upnp:classobject.item.audioItem.musicTrack</upnp:class>
song:subid</song:subid>
song:descriptionun_known</song:description>
song:skiplimit0</song:skiplimit>
song:id0</song:id>
song:like0</song:like>
song:singerid0</song:singerid>
song:albumid0</song:albumid>
song:controls0</song:controls>
wiimu_airplay
dc:titleGood Thing </dc:title>
dc:creatorFine Young Cannibals</dc:creator>
upnp:artistFine Young Cannibals</upnp:artist>
upnp:albumThe Raw & The Cooked </upnp:album>
upnp:albumArtURIhttps://192.168.50.248/data/AirplayArtWorkData.jpeg</upnp:albumArtURI>
song:rate_hz44100</song:rate_hz>
song:format_s16</song:format_s>
song:actualQuality</song:actualQuality>
song:bitrate256</song:bitrate>
nextURI:
nextURIMetadata:
PlayMedium: AIRPLAY
RecordMedium: NOT_IMPLEMENTED
WriteStatus: NOT_IMPLEMENTED
Current transport actions:
Play
Current device AVT service description:
<?xml version="1.0"?> 1 0 DMR-1.50 urn:schemas-upnp-org:device:MediaRenderer:1 WiiM Pro Office Linkplay Technology Inc. https://wiimhome.com WiiM Pro Receiver WiiM Pro Receiver https://wiimhome.com uuid:FF98F09C-ACDE-60F2-FAFE-C257FF98F09C V01-Oct 31 2024 00001 WiiM Pro-0412 FF98F09CACDE60F2FAFEC257 QPlay:2 image/png 48 48 24 /upnp/grender-48x48.png image/png 120 120 24 /upnp/grender-120x120.png image/jpeg 48 48 24 /upnp/grender-48x48.jpg image/jpeg 120 120 24 /upnp/grender-120x120.jpg urn:schemas-upnp-org:service:AVTransport:1 urn:upnp-org:serviceId:AVTransport /upnp/rendertransportSCPD.xml /upnp/control/rendertransport1 /upnp/event/rendertransport1 urn:schemas-upnp-org:service:ConnectionManager:1 urn:upnp-org:serviceId:ConnectionManager /upnp/renderconnmgrSCPD.xml /upnp/control/renderconnmgr1 /upnp/event/renderconnmgr1 urn:schemas-upnp-org:service:RenderingControl:1 urn:upnp-org:serviceId:RenderingControl /upnp/rendercontrolSCPD.xml /upnp/control/rendercontrol1 /upnp/event/rendercontrol1 urn:schemas-wiimu-com:service:PlayQueue:1 urn:wiimu-com:serviceId:PlayQueue /upnp/PlayQueueSCPD.xml /upnp/control/PlayQueue1 /upnp/event/PlayQueue1 urn:schemas-tencent-com:service:QPlay:1 urn:tencent-com:serviceId:QPlay /upnp/QPlaySCPD.xml /upnp/control/QPlay1 /upnp/event/QPlay1Current device RootDevice description:
<?xml version="1.0"?> 1 0 DMR-1.50 urn:schemas-upnp-org:device:MediaRenderer:1 WiiM Pro Office Linkplay Technology Inc. https://wiimhome.com WiiM Pro Receiver WiiM Pro Receiver https://wiimhome.com uuid:FF98F09C-ACDE-60F2-FAFE-C257FF98F09C V01-Oct 31 2024 00001 WiiM Pro-0412 FF98F09CACDE60F2FAFEC257 QPlay:2 image/png 48 48 24 /upnp/grender-48x48.png image/png 120 120 24 /upnp/grender-120x120.png image/jpeg 48 48 24 /upnp/grender-48x48.jpg image/jpeg 120 120 24 /upnp/grender-120x120.jpg urn:schemas-upnp-org:service:AVTransport:1 urn:upnp-org:serviceId:AVTransport /upnp/rendertransportSCPD.xml /upnp/control/rendertransport1 /upnp/event/rendertransport1 urn:schemas-upnp-org:service:ConnectionManager:1 urn:upnp-org:serviceId:ConnectionManager /upnp/renderconnmgrSCPD.xml /upnp/control/renderconnmgr1 /upnp/event/renderconnmgr1 urn:schemas-upnp-org:service:RenderingControl:1 urn:upnp-org:serviceId:RenderingControl /upnp/rendercontrolSCPD.xml /upnp/control/rendercontrol1 /upnp/event/rendercontrol1 urn:schemas-wiimu-com:service:PlayQueue:1 urn:wiimu-com:serviceId:PlayQueue /upnp/PlayQueueSCPD.xml /upnp/control/PlayQueue1 /upnp/event/PlayQueue1 urn:schemas-tencent-com:service:QPlay:1 urn:tencent-com:serviceId:QPlay /upnp/QPlaySCPD.xml /upnp/control/QPlay1 /upnp/event/QPlay1UPnP devices found : 7
Device #0: WiiM Pro Plus-7BC1
UID: uuid:FF98FCDE-FF13-197E-E4BE-DC53FF98FCDE
Location: http://192.168.50.190:49152/description.xml
Manufacturer: Linkplay Technology Inc.
Model name: WiiM Pro Plus-7BC1
Device #1: WiiM Pro-Kitchen
UID: uuid:FF98F09C-DBFA-403B-4C18-7AFDFF98F09C
Location: http://192.168.50.122:49152/description.xml
Manufacturer: Linkplay Technology Inc.
Model name: WiiM Pro-ABDE
Device #2: WiiM Pro Office
UID: uuid:FF98F09C-ACDE-60F2-FAFE-C257FF98F09C
Location: http://192.168.50.248:49152/description.xml
Manufacturer: Linkplay Technology Inc.
Model name: WiiM Pro-0412
Device #3: Denon AVR-X4400H
UID: uuid:3114e67b-e84a-1ef1-0080-0005cde817ea
Location: http://192.168.50.185:60006/upnp/desc/aios_device/aios_device.xml
Manufacturer: Denon
Model name: Denon AVR-X4400H
Device #4: Onkyo
UID: uuid:b06023f9-00f9-23BB-b000-0009b06023f9
Location: http://192.168.50.96:8888/upnp_descriptor_0
Manufacturer: ONKYO
Model name: TX-RZ50
Device #5: foobar2000 Renderer (Mario) [MARIO_CREATOR]
UID: uuid:510e4ed8-5f00-0c07-e5f4-8e906b441e30
Location: http://192.168.50.171:1050/
Manufacturer: Michael Pujos
Model name: foobar2000 Media Renderer
Device #6: Pace RVU Client MediaRenderer
UID: uuid:MediaRenderer-8C_5B_F0_5B_E7_3D
Location: http://169.254.9.26:63445/upnp/xml/devices/MediaRenderer1.xml
Manufacturer: Pace
Model name: C61K
Local
Max. memory for audio buffers: 65536MB
Local Audio Engine: WASAPI
Use max I/O buffer size: ON
Local devices found : 4
Device #0: AI Noise-Canceling Speaker (ASUS Utility)
Manufacturer: ASUSTek Computer Inc.
Model UID: *IGOVAC
UID: \?\SWD#MMDEVAPI#{0.0.0.00000000}.{46fece0e-bf63-4854-9295-882ee4578674}#{e6327cad-dcec-4949-ae8a-991e976a79d2}
Model name: Unknown model
Device #1: Speaker (Sound Blaster Omni Surround 5.1)
Manufacturer: Creative Technology Ltd.
Model UID: USB\VID_041E&PID_322C&REV_0100&MI_00
UID: \?\SWD#MMDEVAPI#{0.0.0.00000000}.{077a684a-0eb9-4152-9081-e33f676b2bec}#{e6327cad-dcec-4949-ae8a-991e976a79d2}
USB Vendor ID: 0x041e
USB Product ID: 0x322c
Model name: SB Omni Surround 5.1
Device #2: SPDIF-Out (Sound Blaster Omni Surround 5.1)
Manufacturer: Creative Technology Ltd.
Model UID: USB\VID_041E&PID_322C&REV_0100&MI_00
UID: \?\SWD#MMDEVAPI#{0.0.0.00000000}.{5b30c6cf-b106-471e-a359-cdfd2f885343}#{e6327cad-dcec-4949-ae8a-991e976a79d2}
USB Vendor ID: 0x041e
USB Product ID: 0x322c
Model name: SB Omni Surround 5.1
Device #3: DELL G3223Q (NVIDIA High Definition Audio)
Manufacturer: NVIDIA
Model UID: HDAUDIO\FUNC_01&VEN_10DE&DEV_0092&SUBSYS_10DE139E&REV_1001
UID: \?\SWD#MMDEVAPI#{0.0.0.00000000}.{f2809abf-f471-4aa0-96ea-d92dbbb74404}#{e6327cad-dcec-4949-ae8a-991e976a79d2}
Model name: Audio Device on High Definition Audio Bus
Chromecast
Chromecast devices found : 6
Device #0: SHIELD
ID: DnsSd#SHIELD-Android-TV-6eb30de427712afcd342587681692ef0._googlecast._tcp.local#0
Model name: SHIELD Android TV
Device #1: SHIELD
ID: DnsSd#SHIELD-Android-TV-9795bcbab0bece80cad3d92970b44513._googlecast._tcp.local#0
Model name: SHIELD Android TV
Device #2: WiiM Pro Plus-7BC1
ID: DnsSd#WiiM-Pro-Receiver-f0cf90a6ab76d9f385c4b3fd13083b73._googlecast._tcp.local#0
Model name: WiiM Pro Receiver
Device #3: WiiM Pro Office
ID: DnsSd#WiiM-Pro-Receiver-2314e53d66bdd15ff51d28c4a93e598b._googlecast._tcp.local#0
Model name: WiiM Pro Receiver
Device #4: WiiM Pro-Kitchen
ID: DnsSd#WiiM-Pro-Receiver-1985a2d971bee04b0b00bfb39ebbaee7._googlecast._tcp.local#0
Model name: WiiM Pro Receiver
Device #5: Onkyo
ID: DnsSd#Onkyo-TX-RZ50-92d2e697f56f78b720c2860fec11d91d._googlecast._tcp.local#0
Model name: Onkyo TX-RZ50
Yes, you are right. As an ex sound engineer, who did some mastering work, I know. I am just trying to figure out why I am getting different readings. I am not evaulating the sound right now. I just want to make sure things are technically set up correctly and what is what.
Hi @Grativana
I use both Roon & Audirvāna - Roon more extensively. Both can have specific ways to configure the playback of the tracks to ensure optimal playback experience of the source track bitrate at the target device endpoint. Roon requires Roon Ready certification to output in the highest resolution over the network without altering the signal before sending so that the end point can play of the track at the higher resolution of the target endpoint on your network. Else the device needs to be attached to the Roon Core. Personally, I do not use any wireless endpoints, bluetooth or Airplay as it significantly reduces the quality of the playback experience.
As you can see above for Roon, each target playback device within each app (Audirvāna has similar options) will also have its own settings - if you want to play with them. The bit rate that is displayed is usually read from the properties in the file (some apps incorrectly display this information) & it will play at either the tracks bitrate or the highest that the endpoint is capable of usually via down sampling if the application sending is capable (Roon & Audirvāna can) or if target device capability is lower than the source files properties. There is a lot of tuning that can be done on both Roon & Audirvāna in these areas, but I have not gone down that rabbit hole into Wonderland yet.
I do know with that Audirvāna Origin’s current version importing a M3U playlist or dropping & dragging the track into a playlist for me on WIN11 Enterprise displays the wrong bitrate (ticket raised) as Audirvāna creates a new entry the SQLite DB for the track & populates the wrong bitrate value in the playlist display only. The track itself in the Library browser has the correct bitrate as it does when playing.
How to see playback bitrate in Roon client:
In Audirvāna you have the option to scan the track so that the app will verify (detected quality) if the Bitrate & resolution of the track is what the metadata in the file says (expected quality).
Selected track from playlist:
Show Settings > Audio Scan
Click Start:
and as you can see this file is a correct 24bit/176.4kHz file:
but you will notice in the bottom right that my DAC (Hugo2) is playing it as 32bit/176.4kHz
That will prove in Audirvāna exactly the expected and output bitrates. if you have a Windows OS you can add the bitrate column to your folders as a check of the files bitrate properties:
Cheers
V/-
You can see in your screenshot, the ALAC file is being decoded in Audirvana and presented to the DSP modules as a PCM 64/44.1 file and subsequently decimated to 16/44.1 for output…
Just a suggestion here… There is little-to-no-reason, for allocating 64GB of playback preload memory… 15GB is a lot of preload buffering… You will notice the CPU cycle percentage increases while the tracks are being loaded in the background into the preload buffer until it is full, and then will settle to minimal cycles… I have 8GB of my 64GB System RAM allocated and I am employing HRTF DSP on PCM up to 24/352.8kHz AIFF files and subsequently modulating all PCM files to DSD128…
@Sir.V.007 Thank you so much for the detailed explanation. I am going to take some time to digest it and come back with questions if I have any. One thing that I am wondering about is your claim that wireless transmission will degrade the signal. I thought using highly capable endpoints, such as the Wiim Pro Plus and a player such as Audirvana would insure a bit for bit accurate playback at the highest fidelity. Am I wrong in that assumption? Most of my endpoints will be ethernet connected, if they are not already. Would that make a difference?
@Agoldnear Thank you again for clarifying and for your suggestion. I will lower the RAM. Actually, I think I screwed up and installed Audirvana on my workstation rather than my server. I assume it would be best to have it running on that even though I listen through my workstation. The workstation has 128 Gb of RAM and will get more in the future.
Yes… There is no error-correction on both wireless and Ethernet transmission of digital-audio signals via UPnP protocol, so there are many potentials in the transmission that can-and-will influence the integrity of the bit/packet-stream and playback performance/reliability… As a sound engineer, you should have a clear understanding of these potentials.
Ex-sound engineer. Stopped engineering in 2006, after doing it for 17 years, but I still know and play with a lot of stuff, However, the whole wireless transmission through wifi is fuzzy for me, so no, I don’t know what the potentials are, not that it matters that much. The important thing to know is that there is a potential for problems, which is disappointing to hear. I thought the Wiims had hardware that ensured perfect playback, but as I said, my knowledge is fuzzy on this subject matter.
I am starting to think I am going to have to put all those XLR balanced connections I laid in parts of my house for streaming music. I thought I was going to be able to forgo the old school methods but I have spent hundreds if not thousands chasing the promises of high fidelity playback through wifi streaming and this new tidbit is another gut punch. I tried not to be an early adopter of this, and am not, but it seems not all is rosy in wonderland. Thanks for opening my eyes to this!
I guess for streaming it is not the most important to hear perfect playback. Who is listening that intently to background music? I can at least use a local DAC (topping D50 III I am currently considering) and feed that to my monitors for critical listening. I could do the same with my bedroom and Florida room systems as they each have local computers, or transformer split the topping to each of the rooms through XLR. I guess I have more thinking to do.
I agree with background music listening as being less-than-critical
In regard to some fundamental principles in distributed digital-audio signals… Let’s just start with the power/ground/earthing differential potentials of devices connected via wire to each other, that will precipitate noise influences on the digital-audio bit/packet stream that will add to the ‘jitter stew’ due to leading and trailing edge misreads at the interpolation level and worse case, data loss… And then there are latencies inherent in the transmission path-lengths… Just some food for thought.
Note: Fiber-optic transmission to the DAC will isolate it from transmission line gremlins (as does wireless)… you just need to manage your power/ground potentials at the endpoint.
In regard to high-resolution digital-audio wireless network distribution… @Djm1960 seems to have designed a very reliable and high-performance WiFi system… You may like to read some of his threads regarding his network and playback system. Others like @Jud have excellent insights into managing detrimental influences on the digital-audio bit/packet integrity and managing power/ground/earthing noise potentials inherent in Ethernet distribution systems and the mitigation of those potentials… If you search around here in the Community forum you will gain a lot of insights that may apply to your particular playback system configuration.
Hi @Grativana
In terms of my comment in the regards to the quality of wireless endpoints this is based on what I have read on the topic (basically other ppl’s opinions & some “science”). Apple’s Airplay & the various Bluetooth (BT) codecs are restricted because of their bandwidth (for BT). Personally, I don’t like how Spotify lossy (non-HiRes > 24bit/44.1kHz) & airplay connections sound for listening to music.
Airplay has restrictions in terms of max resolution that can be played over that protocol. For most people this is fine, for me it is not. If I play the same track on Spotify then to it on Qobuz & then on Tidal, both Qobuz & Tidal sounds better to me & others i have asked too do the same test with music they know well. This is even for CD quality tracks @ 16bit/44.1kHz.
Qobuz & Tidal may have higher resolution options of the same track to listen to. In Roon if you click Versions & you have configured both Qoboz & Tidal streaming services you can see your local library version as well as the streaming service version. Audirvāna’s Studio has the option to add these streaming services if that is the version you are trialing, you should be able to do something similar. I only have Audirvāna Origin.
If we take a classic 80’s pop album like Thriller:
Using wireless to play DSD64 over BT will be compressed to a point and it will not sound as good as a network or USB wired endpoint. Even using PCM 24/176.4 or 24/96kHz it will not sound as good IMHO vers a wired connection - using “better” quality cable. With aptX HD & LL codex is up to 24/48 or 96kHz. I have done a fair few shootouts and A/B testing between devices, from different sources, over BT, different cables, interconnects, protocols, software and source devices of the same tracks of the same & differing resolutions. I use up to AudioQuest’s Vodka ethernet cable, Cardis Clear & Curious Cables network cable ranges & for USB I use up to AudioQuest Diamond, even up to $800 power cables & Audiolab’s DC block (I have not yet gone to PSAudio’s P12 Powerplant to produce a “perfect” power sinewave yet) all of which have an impact on what I am hearing. Including isoACOUSTICS isolator pucks for under my equipment & speakers isolation feet. I have also listened on Silent Angel’s entry point Audiophile network switch to see if I can hear an improvement over my Asus gaming routers. Back to wireless, the further away your wireless endpoint is from where it is being broadcast the more the strength of wireless signal degrades. In my network my WiFi strength drops from 350mbps next to the router to 150 upstairs.
In an Audioquest listening session event with up to $AUD100k speaker cables for a 2 pair @ 3m length & various level USB & ethernet cables they mentioned about transmitting wirelessly in how it breaks apart the signal to transmit it - which impacts the quality of the data (change protocols from wired to wireless) - so getting pure bit perfect at the target may be a challenge in a wireless scenario. I have wireless transmission between my AIMesh routers or access points & devices plugged in via ethernet cable at each node. With this setup I find it difficult to hear the difference of a signal sent from my Roon Core wirelessly between each router via ethernet cable into my Lumin T2 or EverSolo Masters DMP-A6 vs SSD connected or installed in either device. The Lumin T2 is capable of DSD512 as a Roon Ready endpoint - these files are MASSIVE in the GBs for 1 track vs the same file size of an MP3 at 320kbps or at the Apple AAC BT protocol max bandwidth size.
Happy to provide my perspective.
Cheers
V/-
It is not possible to transmit native 1-bit DSD64 or via DoP (DSD over PCM) via BlueTooth, as the DoP PCM carrier for 2.8MHz 1-bit PDM (DSD64) is 24/176.4kHz… DSD will need to be decimated to a PCM sample-rate that is transmittable via BlueTooth.
Both the Lumin T2 and Eversolo DMP-A6 utilize the ESS chipsets which do not support a pure 1-bit PDM (DSD) signal path… All signals, including DSD (decimated to a lower resolution PCM sample-rate in the SDM module) , are presented as a multi-bit PCM signal for delivery to the output circuitry of these chipsets.
hi @Agoldnear
Thanks for the info in the ESS chips, I was not aware that they decimated to lower resolution PCM in the SDM module - I’m not an expect. I am aware that this happens on my Hugo2 (Hence why I have issues with it when switching between hi-res DSD & PCM tracks in a playlist & vice versa) no matter whether I am playing via Roon or Audirvāna.
This would explain why that neither of these devices of mine are listed here as DACs that play bit perfect DSD: NativeDSD Database - Google Sheets
In terms of my comment on DSD64 over BT, that is the resolution of the source file, I wasn’t getting into the detail of what happens to the track on the target DAC chipset (which I totally admit I wasn’t aware of) or what is happening on the sending application or the receiving device endpoint software in the communication path before hitting the chipset (whichever point in the end-to-end communication is actually decimating the file to send or receive in the bandwidth available via BT before it hits the DAC chipset??), only that it doesn’t sound as good to me as it does via a wired communication medium. Obviously (to me) the track needs to be “decimated” (love this term by the way) at some point when using BT - I would expect that this happens on the application providing the source track before it is transmitted over BT for it to fit within the transmission signal’s available bandwidth? not sure sorry. I was only communicating my observations of how it sounds to me when I have used that medium.
I do appreciate the information as I love learning new stuff so am happy to read this. I will keep this in mind when discussing my perspective in the future.
Cheers
V/-