mp3 playback over SMB frequently interrupted

[rillke]

I can reproduce this issue under Windows 10 with VLC 3.0.8 Vetinari, not under MacOS. I haven't tried Linux; if someone believes this is important, I'll do. I cannot reproduce this issue with m4a/aac and ogg/opus files (i.e. they are playing fine).

Here is what I am doing:

1. Start with new settings by moving C:\Users\someUser\AppData\Roaming\vlc to C:\Users\someUser\AppData\Roaming\vlc_old
2. Have a network drive at a remote location.
3. Have some audio files of different types (mp3, ogg/opus, m4a/aac) with approximately the same overall bitrate.
4. Have a connection bandwidth capable of handling the played audio files within one or two seconds when copying with Windows Explorer.
5. Connect to the network drive using SMB 2 via Windows Explorer (enter URL \\networkurl\share) and provide the credentials.
6. Drag and drop the mp3 file to the playlist.
7. Starting playback.

Here is what I see (and hear):

1. Buffering is much slower compared to ogg/opus and m4a/aac in spite of similar bitrates
2. Playback starts and lasts for a couple of seconds
3. Playback interrupts and buffering starts (very slowly again)
4. Playback starts and lasts for a couple of seconds
   ...

At pastebin.ubuntu.com is log of

1. m4a playback: https://pastebin.ubuntu.com/p/gZMtXgqkx4/
2. mp3 playback: https://pastebin.ubuntu.com/p/fwkmrw9hjb/
   
   
   And I have captured some traffic with Wireshark. I have also full capture files and recorded a video from screen, however it may contain sensitive data and I am only willing to share it with developers if they agree on an NDA. The video features the Wireshark and the VLC messages window running in parallel.
   
   Here are some screenshots. The most obvious part: Much more yellow in the mp3 capture. This means the initial SMB packets/TCP packets ratio is increased. The overall number of packets in the mp3 capture is also much higher compared to the m4a.
   
   Playing m4a:
   1/4
   
   2/4
   
   3/4
   
   4/4
   
   
   Playing mp3:
   1/3
   
   2/3
   
   3/3
   
   
   Note: Increasing buffering durations in settings does not really help: Longer playback but also longer breaks within one title. Find a copy of this post on https://github.com/Rillke/public-forum-images
   
   The obvious question is: How to fix it? Should I open an issue/ticket/bug?

[d4rky89]

Hello everyone,
I'm here because I have this issue, too. 2 years ago I have moved my audio files to a NAS and playback experience with VLC is really bad since this day. Especially, playback over Wifi is lagging like hell, though the throughput is more than high enough with effective 10 MBit/s connection (sitting in the garden) streaming files having at most 350 kbit/s of data rate (Mp3).

I've took some time to monitor VLC's caching behavior. I came to the conclustion that the file caching behavior is simply wrong.

How the cahing algorithm behaves (with caching set to 1000 ms):

1. VLC "playbacks" the audio file in realtime for 1000ms "silently" into the cache.
2. After 1 second "silent playback" into the cache, VLC starts playing back the cache to the audio device.
3. Parallel to the real playback, the caching algorithm plays back the audio file in realtime into the buffer.
   • The problem here: VLC is requesting the file data in realtime, i.e. its requesting chunks for a 1x speed playback. But it does not respect network latency when getting this data.
   • As an example (not related to real file formats), we have a file with 350kbit/s data rate. The cache requests 350kbit data. As soon as this data has arrived, it waits 1000ms to request the next 350kbit data and so on... But since we have network lag, requesting one chunk of 350kbit data takes like 1100 ms. This results in effectively fetching less than 350kbit of data.
   • Besides this problem, setting the cache value to 30 seconds, requires us to actually wait about 30 seconds, though the cache could be filled in no time when streamed from a network drive.

If the total playback duration is high enough, no matter how high you set the playback cache, it is guaranteed that the playback buffer becomes empty and we have a playback gap equal to the cache time.

How caching should actually work:

1. VLC "playbacks" the media file with the maximum possible speed into the cache buffer
2. As soon as the cache is filled to the point where 1000ms "offline playback" can be guaranteed, the actual playback starts
3. While the cache buffer gets drained due to playback, the cache algorithm should try to fill it back to 1000ms "offline playback" with the maximum speed the playback source can provide.

With this caching algorithm we get:

• Cache buffer filling as fast as the playback source can handle
• A guarantee that the cache buffer will never get empty if:
  • Our source can provide data faster than 1x playback speed
  • The average connection speed is at least as high as 1x playback speed bandwith
  • The network cache value is high enough to compensate connection speed jitter (especially important for Wifi connections)

Regards, d4rky

[Rémi Denis-Courmont]

SMB/CIFS implementations are not suited to streaming. Specifically, they can't do pipe-lining which is basically what you describe. As this is Windows code, there is not really an option to fix it in VLC.

Use HTTP or FTP.

[Cuisto]

Hello,

I've the same problem using VLC 3.0.12 on Windows.
Older releases of VLC hadn't this problem (don't really know well this problem occurs, but my mp3s are on nas since years).
Other players don't have this problem, so even if smb isn't suitable for streaming, they succeeded to manage such cases.

VLC for Android 3.3.2 don't have this problem : i can play same mp3 without problem. Is there a big difference of buffer implementation ?

As a solution, we can copy files on local drive, or use another player, but it would be very great that vlc can play such files : it very common.

thanks

[Rémi Denis-Courmont]

VLC for Android has its own SMB implementation inside, and I understand that its most recent versions have been designed to handle streaming/pipelining fine. VLC for Windows uses the OS implementation by Microsoft; and this cannot change lest it break single sign-on and infuriate users.

[SatoriTindalos]

VLC for Android has its own SMB implementation inside, and I understand that its most recent versions have been designed to handle streaming/pipelining fine.

That understanding is incorrect. I've been using it and continue to have the problem unabated.

But it's nice to know why VLC hasn't fixed it yet; the developers thought they already had.

Try upping the Playback Speed on the device; that usually drastically increases the frequency of the problem.

[Rémi Denis-Courmont]

Err, maybe the problem is not fully fixed in VLC for Android, but the implementation of SMB in VLC for Android is very definitely different from that in VLC for Windows. Also while the Android implementation could probably be fixed eventually, the Windows one cannot since it ships within the Windows OS.

[SatoriTindalos]

Err, maybe the problem is not fully fixed in VLC for Android, but the implementation of SMB in VLC for Android is very definitely different from that in VLC for Windows. Also while the Android implementation could probably be fixed eventually, the Windows one cannot since it ships within the Windows OS.

Your answer helped considerably.

Since the problem is mostly on the W█ndows side, I went and made sure my SMB installation was updated and enabled rather than just the version that came with the OS. Now my lags when viewing on a device only happen when I'm pulling quite a lot of data, happen far less often, and my shared folder content updates automatically rather than having to re-share it each time to force the content to appear. The brunt of the problems have been alleviated because, just as you say, the majority of the problems are on the W█ndows side.

Leaving this here as a solution for others having these problems.

Kind thanks.

[reza1]

I indeed have the same issue, found this thread and read carefully.

I've ran a couple of straight-forward crossed tests that give me confidence the issue can be narrowed down to VLC's implementation of cache on audio files specifically.

The base example is trying to play a recording (on VLC 3.0.16), mp3, 192kb/s - freezes about 25 to 30 times per minute.

• The same file read on VLC 2.2.5.1 (latest 2.x I could find) ran smooth, no freeze noticed in 1h play time
• If I mux the exact same audio file with a random video (mp4 or mkv, both produce same result) that weights 3282kb/s more on the same connection, then VLC 3.0.16 is suddenly able to render the resulting 3474kb/s file perfectly smoothly

I'm unsure what exactly is at play on 2.2.5.1 but I can testify that 2.2.5.1 is just fine playing audio files over SMB, and I'm adding that it worked for SSO, kerb5 and NTLM tickets (tested).
I won't argue that SMB is the best candidate for streaming protocols (I don't expect anyone could), yet it's widely spread, especially on Windows devices, but also home NASes etc. and when the throughput is outrageously sufficient (2.5gb/s vs 192kb/s) and the IO response time are a fraction of the time covered by the cache (<10ms round trip vs 1500ms) one would expect things to "just work".

I understand there isn't much to pinpoint where start an investigation here, yet test #1 suggest it's a regression (or speudo-regression I suppose if the architecture has significantly changed between the 2 major versions), and #2 is particularly baffling and frustrating, we're left kind of "if it can play it as part of a video, why on earth can't it play it alone? "

[Rémi Denis-Courmont]

VLC 2.x had the same problem with SMB. It just showed up for different combinations of media bitrate and network bandwidth & latency. And VLC 4.0 will have the same problem too.

The problem is not the SMB protocol as such. The problem is the common implementations of the SMB protocol: they are either implemented as a virtual filesystem inside the OS (notably Windows or Linux SMB drivers), or as libraries providing filesystem-like interfaces (incl. Samba's libsmbclient). Those interfaces just can't do streaming/pipelining. The only way to fix it is to use a different implementation that supports streaming.

VLC itself is able to cache media properly, and that works fine with HTTP and FTP, which have ad-hoc implementations inside VLC, specifically to support streaming.

With that said, in my opinion, switching to HTTP or FTP to stream media over the LAN seems much more pragmatic than replacing the SMB implementation inside VLC for Windows. But if you want to try the latter, I believe that you are welcome to submit patches.

[jumpingjackflash5]

I can confirm I'm having these issues even with the current 3.0.20 version on Windows, on 802.11n wifi connection (50-60 MBit/s bandwidth), x264 mp4 files.
What helps, but does not fully prevent this behaviour, is to increase the file cache to 1000-2000 ms, because VLC uses the Windows filesystem (not streaming/prefetch) for playing SMB files (even from UNC names, not only drive letters).
Anyway I tried the proposed moving to http, e.g. I have run the basic media server on my Synology NAS and chose the DLNA for playback. But this exhibits even worse behaviour in my case, as usually after 30-60 seconds, the VLC player starts to occupy approx. half of the bandwidth in task on wifi, but even so on gigabit connection (see the picture). I doubt it can actually transfer that amount of data (as the files I try are max 200-300 MB in size), it plays smoothly during that time, but still then irregularly stutters especially on wifi (but the behavior is not deterministic, sometimes it can play an hour OK, and then stutter a lot) . It buffers nicely only at the beginning of the transfer, or sometimes on smaller files (<50 MB).

https://1drv.ms/i/s!Ah52o66BmtNAi9N6L2H ... Q?e=crggql

Simple Movies and TV app plays both paths (SMB and HTTP-DLNA) with correct network usage and only very exceptional stuttering on Wifi.

What is suspicious is that in the log when playing HTTP/DLNA these entries with connection failed and then streaming appear. But I could not figure out why.

https://1drv.ms/t/s!Ah52o66BmtNAi9N7XAy ... A?e=D3a7Vi

If you have some hint how to improve either SMB or HTTP/DLNA playback, I can try them. But I have little hope considering the length of this thread.
For now I'll keep using SMB and bigger buffer, which is usable.

[nuk]

I have to restart VLC 3.0.20 after applying cache changes for them to take effect. Max 60000 buffer takes an obvious amount of time to load for me, and I can tell the loading doesn't change unless I restart VLC.

[jumpingjackflash5]

I did the restarts after buffer changes, too. But even if I do so, the behaviour does not change.