Local Devices Music Library & 48khs audio

I’m not sure I understand. Sonos still offers playback of local files from your computer. No need for an NAS, but your computer and drive need to be on. You may need to reset access to your local library, by resetting it up, but as far as I’m aware, it still works. 

It's not local if my device is my phone. I dont want to have to use a computer. That's the stupid part. Why can't Sonos just allow me access to my phone local music library through their s2 app and play from there?

That would make simple and easy sense, right.

I think with a NAS there is no need to have a computer or laptop and I can integrate direct into the S2 app controller?

If the device is your phone, the makers of the operating systems have blocked Sonos (and everyone else) from using it to access data streams from an outside device. It  isn’t, unfortunately, up to Sonos at all. I suspect if the OS makers would allow it, Sonos would be offering it. Which has been discussed in many, many threads since the OS manufacturers have blocked Sonos. It would be easier, in this instance, if the Sonos app was really a ‘player’ on the phone, as then it could ‘cast’ the signal to the speakers. 

Depending on your Sonos device, you can still use either a Bluetooth or AirPlay 2 to send a signal from a player on the phone (not Sonos). 

Not sure you can install an NAS without a computer, but certainly Sonos won’t care. As intimated above, the system (Linux) running on the Sonos reach out to the NAS and play directly through that connection, not through a PC or a phone. The controller device is merely a ‘remote control’ to tell the application running on the Sonos device where to get the data to play. 

Bluetooth and AirPlay solutions won't work because those will resample 48khz tracks. AirPlay 1 is only capable of 44.1khz and AirPlay 2 only streams at 48khz if its a video with audio, not just audio.

If music players on my phone can access my local folder library, why can't Sonos?

Because ‘Sonos’ doesn’t play on your phone. As explained in my previous post, the controller on your phone is merely a remote for the application that runs on your Sonos devices. 

​@Scott Campbell 

As Bruce said the discussion about „playing from this device“ is obsolete since os developers don’t allow access to apps that put audio out on a different device. 
Next point is that a NAS is a different thing than a smb network share. 
Sonos S2 just needs a smb2 share to add a path for the Sonos music library. 
The device where the files are on also can be a USB stick connected to your router, if the router supports a smb2 share option. That‘s the wasy I use it and can play my local audio files with 24bit 48kHz audio quality. 

It’s not accurate to state that Android is blocking access to local devices for media streaming. It simply requires the correct permissions and security settings to be granted.

This is a feature they chose (not were forced) to remove from their app, which I personally find frustrating.

Other apps (such as VLC and BubbleUPnP) work directly on phones to stream local media to compatible devices without requiring a separate media server or additional hardware.

Why don’t I just use one of them, you might ask? Because Sonos only guarantees the 48kHz sample rate when files are played via their S2 app controller.

I have a Telstra Smart Modem 3 with a USB port, so I could plug a hard drive or memory stick into that and enable SMB sharing. Do you notice any lag at all with this when playing tracks?

I might need a bit of guidance on adding the path in the Sonos S2 app.

I've always understood the feauture is blocked for anything else than music/video players. Since the Sonos app does not count as such (it's a remote), the feauture is off limits to Sonos.

Android policies do not block non-music/video apps from accessing local files. BubbleUPnP, which operates primarily as a controller (and optionally as a media server), and X-plore File Manager both demonstrate that accessing and streaming local files is entirely feasible under Android’s rules. This highlights that Sonos’s decision to remove this feature was a choice rather than a technical limitation imposed by Android.

That’s the whole point.  The Sonos app is not “accessing local files”.  The Sonos app is a controller, it’s not accessing anything local.  It’s the Sonos hardware that accesses and plays the file/stream directly (try playing a playlist, then turning off your phone for proof). The app merely tells the Sonos hardware what to play and where to find it.  And if the “where to find it” is the controller device, the Sonos hardware would need outside access to said controller device, which Apple, and later Android, have most certainly blocked. 

So you are incorrect.  This is not “a choice rather than a technical limitation”.

The claim that Apple and Android restrictions forced the removal of local playback oversimplifies the situation. While these restrictions introduced challenges, they didn’t make local playback unworkable—other apps, such as VLC, successfully implemented solutions like sandboxing and temporary file caching, which are widely adopted practices in modern app development. The Sonos app’s previous support for direct local playback proves it once delivered functionality far beyond being just a controller. Sonos made a deliberate decision to shift its priorities, investing in SMB sharing and streaming services instead of exploring feasible options to retain local playback. This strategic shift was a choice, not a necessity, and to suggest otherwise misrepresents the app’s history and the technical possibilities that were clearly within reach.
 

You can assume all you like about this being a deliberate decision, which it wasn’t, but the fact remains playing content from these devices is not possible via Sonos the reasons have been given. 

Sonos disabled it as it was the only thing they could do as it would stop working.  It likely will never be restored as there are perfectly good alternatives.  Your use case is also quite niché and would likely feature low in any Sonos enhancements, even if it was possible..

Did you even read my post?  The fact you keep comparing the Sonos CONTROLLER app to a MEDIA PLAYER app like VLC is proof you either didn’t read, or don’t understand the difference between the two. Furthermore, there was never any “previous support for direct local playback” from the Sonos app.  Every Sonos app ever released PLAYS NOTHING, so any point about local access means nothing.  Just the same as every other source - SMB libraries, streaming services, radio station URL’s, etc. - the previous Sonos apps told the Sonos hardware to play files on the controller device via outside access, something the OS manufacturers have now banned due to security issues.  

​@Scott Campbell 

And just to answer your question… Sonos music library playback via smb2 share from my usb device that is used as routers nas storage workes absolutely fine. 

As further proof that this was the fault of the OS manufacturers and not Sonos, if Sonos made a “deliberate decision to shift its priorities”, why would it end playing from an iOS device back in 2019, but kept the function going for Android until 2023?  Four years is a pretty long time to “deliberate” a shift in priorities.

Your explanation hinges on a misrepresentation of my points. I did not compare the Sonos controller app to VLC as a media player. I referenced VLC to demonstrate the feasibility of technical solutions, such as sandboxing and caching, which could have been implemented to retain local playback functionality despite platform restrictions. Similarly, I cited BubbleUPnP and X-plore File Manager to show that local file access is entirely achievable within Android's policies—not as functionality comparisons to Sonos.

Your claim about ‘direct local playback’ is semantic nitpicking. While the Sonos app didn’t play files itself, it facilitated playback by accessing media stored locally on the controller device via Sonos hardware. This constitutes local playback in practice. Furthermore, the argument that platform restrictions rendered this feature impossible is demonstrably false—other apps have successfully maintained similar functionality within the same constraints. Removing this feature was a decision, not an inevitability, and reflects a choice not to prioritize a solution.
 

Your assertion that local playback is a niche feature ignores clear evidence to the contrary. The removal of this feature sparked backlash across forums, including the Sonos Community, where users repeatedly emphasized its essential role in their experience. Local playback allowed users to directly access their media libraries without relying on streaming services or cloud storage, delivering autonomy, simplicity, and reliability. For many, this feature wasn’t a secondary convenience—it was a core component of the system’s functionality.

Sonos’s proposed alternatives, such as NAS or SMB protocols, introduce unnecessary complexity and fail to replicate the immediacy and ease of direct local playback. Technically, retaining this functionality was feasible—other apps have successfully implemented sandboxing and user-managed file access to comply with platform restrictions. Removing this feature without offering a comparable replacement dismissed its clear value to the user base and overlooked its demand.

Your framing of the timeline distorts the realities of platform restrictions. While Apple introduced stricter policies in 2019 that blocked local file access, Android maintained flexible mechanisms for an additional four years, enabling Sonos to retain local playback on Android devices during that time. Even after those four years, Android’s policies did not impose a total block on local playback functionality. Apps such as VLC and BubbleUPnP demonstrated the feasibility of local playback by utilizing compliant frameworks like user-managed file access and sandboxing.

This timeline reflects missed opportunities. Sonos had the technical capability to adopt similar solutions to preserve local playback across both platforms, as other apps have done. The removal of this feature was not dictated by platform manufacturers but was instead a deliberate choice made by Sonos to shift priorities away from retaining this functionality. The availability of feasible solutions underscores that this decision was avoidable.

You say semantic nitpicking, I say actual rules laid down by the OS manufacturers that, when broken, will get your app removed from their respective stores.  Tomayto, tomahto. 

Whatever.  I wasted way too much time on this.  Keep hoping you are right, though.  But you know what they say “Wish in one hand . . .”