Broadcasting under Windows - unstable stream (buffering)

[Hubert Burkert]

i have no way of testing this bug under diffrent operating systems than windows.

i verified the bug with windows-xp, XP64, win-7 (32 and 64 bit), with the 32 and 63 bit version of mix 1.11
i testet it with diffrent sound setups, usb, firewire, and onboard soundcards, ASIO makes no difference.

i testet broadcasting with the build in ogg-vorbis encoder, and the recomendet lame-enc in mp3 codec, the effect is always the same.

when broadcasting the stream is VERRY UNSTABLE - its buffering a lot. the data rate goes up and down rapidly.
it falls far below the streamrate wich causes lags (buffering) on the receiver side.
then the dara rate goes up again and goes down again.... it looks like a "Pumping"
the problem is independent from the server used icecast, or shoutcast makes no diffrence the effect is alwasy the same.

we use the broadcast tool "BUTT" with an additional audio interface and a cable bridge, to work around this bug, but it realy would be nice if broadcasting directly with mixxx would be stable.

By the Way - an Equalizer for the Microphone would be a great feature for broadcasting.

[Florian Kiekhäfer (technik-zwr)]

This confirms my impression of this happening more often with mixxx than with edcast. However i personally won't go that far to say that it is always unstable.

But up until now i have no idea, what may be the cause.

[RJ Skerry-Ryan (rryan)]

I think this may be drastically helped by the combination of Bug #1179027 and Bug #1194543.

[RJ Skerry-Ryan (rryan)]

Adding to 1.12.0. Once a beta is available I will need testers who can reproduce the problem to verify the fix. Hubert / Florian -- are you still able to reproduce?

[Hubert Burkert (hubert-gsm)]

Yes i can still reproduce the problem, everytime i try to use the internal Broadcast funktion on mixx.
i have icecast and shoutcast servers i can use for testing, independent from the stream codec, ogg oder mp3 the problem is always the same.

im running a webradio Station (www.gothdimension.de)

in my own studio the bug is no problem for me, cause i use an analog studio mixer (Behringer Xenyx 1622dx) for the "On Air Mix" and im broadcasting using "butt" (http://butt.sourceforge.net/)
By the way "Butt" is the most rock solid broadcasting tool ive ever seen enywhere.

So in my personal Studio setup MIXXX is just the Music Player, conected to my Studio Mixer, but some of the other Moderators on my Station would like to use Mixxx directly, and they cant because of the bug.

We have a lot of dirty workarounds here, like broadcasting from the "stereo mix interface" in windows-xp by Using Butt.

and of course i would love to test the new Beta Version for this Bug. and i know at least 2 more people connected to our station who would test it too....

Thank You

feel free to contact me for any live tests.
i have a testserver with identical configuration as the main server

[Owen Williams (ywwg)]

can someone check in on this again? It's been a long time since march even though I don't think we've touched this code a whole lot

[Dennis Rohner (midzer)]

Running Mixxx 1.11 under Win7 64bit, stream listeners experienced a stable stream if my internet connection has enough bandwidth available.
So i cant reproduce those effects original poster mentioned under 1.11.

On the contrary, in my latest live show using 1.12 beta1 users reported severe hanging/laggy stream (no bandwidth consuming application was running at my pc).
With me having the same stream recorded in Mixxx, i heared lags or hickups in file playback every ~30s.

[kFYatek (kfyatek)]

Sadly, I need to confirm this. I've been using Mixxx 1.12 to broadcast web radio shows for over a year, with no problems. Today I tried 1.12.0-beta1 (1.12-r5442, Win64). My listeners reported that after about 30 minutes into the 2-hour show, the stream started getting "hiccups" as if the Internet connection was failing. At the end the stream was about 15-20 minutes behind live input, and those never got on air.

Win7 x64 SP1 with all the latest updates.

I love all those changes and features in 1.12, the build seemed very stable at my end, it was a pleasure to use, but it's unusable for me without a stable Icecast output :(

[kFYatek (kfyatek)]

I meant I've been using 1.11 for the last year, obviously, rather than 1.12. Sorry for the typo.

[Tuukka Pasanen (pasanen-tuukka)]

Is this buffering problem or network problem. I assume that this drops Mixxx side and people have enough network badwidth. Can you check if you save that streamed Ogg is it 'correct' and it there caps inside.

[kFYatek (kfyatek)]

Actually, I was streaming MP3. And I was also recording an MP3 file of the whole show and it sounds as it was meant to sound; the whole show is recorded and there are no listening problems.

I don't think this is a bandwidth problem. I could hear the problem when I listened to my own stream from another application. Also, when I restarted Mixxx and started streaming again (just a test stream for about 10 minutes), everything was OK. It looks like something caused the broadcasting module to "lose sync" and make it stream slower than it should after some time. Maybe it was when Mixxx was busy with something else (like loading files). This is all just speculation, though.

[Tuukka Pasanen (pasanen-tuukka)]

Are you using Icecast or shoutcast server. I have been using Icecast and it works like that when your buffer drowns down. Did you record it from Mixxx or from stream to file?

[kFYatek (kfyatek)]

The server runs Icecast 2.3.3. I was recording from within Mixxx (Ctrl+R).

So, do you have a fix or workaround for this issue?

[Tuukka Pasanen (pasanen-tuukka)]

Ok so you streamed and recorded same time. I'm just gathering background info to test this with Icecast server.

[Tuukka Pasanen (pasanen-tuukka)]

Can you send console output of mixxx when this happens. Reproduction was harder than I though. Most of the times it works as expected.

[Tuukka Pasanen (pasanen-tuukka)]

Problem seems to be like I assumed cache is draining down. We cannot encode as fast as libshout demands. But can @kFYatek or @hubert-gsm test with very low rate mp3 is it working (start the lowest 32 and go up until you get to the point where is breaking). Question is how much buffering we can stand?

[kFYatek (kfyatek)]

I will try testing it when I have time, although it won't be easy as it takes some time in the order of an hour to reproduce. And I can't afford doing this during public broadcasts.

It seems natural that the buffer may run down. But there are more buffers (probably on the Icecast server, and in the client applications) to mitigate the problem. The problem is - why is the stream becoming permanently broken after such failure instead of just refilling the buffer and recovering?

[Tuukka Pasanen (pasanen-tuukka)]

If I'm correct and hopefully I Am Icecast never can fill cache because Mixxx doesn't supply enough bytes to fill it before clients drown it faster but I investigate this more.

[Daniel Schürmann (daschuer)]

It looks like there is a scheduler concept issue or something.

The raw samples produced with the engine audio buffer size are transfered by a 750 ms @ 44100 Hz to the SideChain thread running at QThread::HighPriority.

The side chain thread is scheduled once the buffer is occupied by 1/5 = 150 ms.
The raw samples are encoded and send to a non blocking socket via shout_send().

All encoded samples that are not able to send because the socket is occupied are queued inside libshout, in a dynamic allocated buffer.

I think it is intended that the side chain runs less often to save some cpu cycled for rescheduling.
But I am afraid this way the scheduling it is not that deterministic, which leads to the pending issue.

Which cache runs out?

In case the SideChain is not scheduled in Time, some samples are lost since the 750 ms buffer is occupied.
Changing the encoding bit rate will not change the issue much since the buffer contains raw samples.
The missing sample buffer will lead to a click sound, since to non continuous samples are connected
and the server buffer gets slowly down.

An other place for the buffer issue is that due to an occupied socket a 150 ms chunk might be copied to the cache.
But we do not try to reset it immediately, only after a noter chunk of 150 ms is available.
By luck, the socket is occupied again and the cycle continues with a growing number of 150 ms chunks.

If this takes too long, the buffer of the Icecast server will running out and the stream stops.
Once the socket is free, the stream continues with a delay since no sample is lost.
I think I have read on the forums, that there is an issue with a growing delay up to 10 min.

What do you have, click sounds or a growing delay.

Any ideas how to solve the issue?

Running shoutcast from the engine thread, will solve the first issue.
Running shoutcast in blocking mode from its own thread will solve the second issue.

Or we can do a band Aid:
* Adding silence if 750 ms is running full
* Flushing the socket cache if the server buffer is empty anyway.

[Daniel Schürmann (daschuer)]

By the way: Equalizer for the Microphone is Bug #1277274
@Hubert Burkert: Please add your use case to the Bug. Which EQ do you need. How should the GUI look like?

[Daniel Schürmann (daschuer)]

> The problem is - why is the stream becoming permanently broken after such failure instead of just refilling the buffer and recovering?

This is a second issue. It looks like Mixxx has no recovery path for such a case.
Do you have a mixxx.log file from faulty run?
Watch out for:
 "DEBUG: Send error: "
 "DEBUG: queue length:"
 "Error connecting to streaming server:"

@Tuukka: Can you reproduce the "permanently broken" issue?

[Tuukka Pasanen (pasanen-tuukka)]

This 'SHOUTERR_BUSY' thing is easy fix just launch 'shout_sync(m_pShout)' (which should be performed anyhows before send to prevent BUSY).
@dashuer I can nail it down in my laptop (which ain't top of the notch) choose MP3 320 bits per second for encoding. After that shout_delay (which tells you how much we have to wait to send next packet to server) if negative which means we are running behind scheduled and it means Icecast server never can cache anything because we don't feed fast enough. After that running something like (sorry tested this on Linux :D) mpv/mplayer it complains that it cannot cache bytes and cache runs as low as 2s. If I choose lower than 192 everything goes smooth if there is no calculating waveforms.
So you can test this to place 'shout_delay' (http://www.aelius.com/njh/libshout-doc/libshout.html) qDebug() before and after shout_send and see if it turns negative and that is why I asked people to test with different bits rates.

[Daniel Schürmann (daschuer)]

Thank you for the explanations.

It look like we have a strong sync issue here. The Server seams to has its own idea about sample consumption rate, (its own crystal clock) this may not match the crystal clock of the master sound card. So we are facing the same issues we do in 1.11 where we have a click in the headphone sound card.

The difference here is that the "clicks" are aggregated to over the caches to a single "break" of the connection.

Currently we cannot call shout_sync(), since this will sleep the sidechain thread, but this must not happen since the thread is not exclusive to shoutcast.

I think the best solution would be like this:
* Move shoutcast to its own thread.
* use the blocking sockets
* use shout_sync().
* fill a dedicated FIFO from engineMaster.
* don't sleep the thread at the buffer.
* use a buffer leveling algorithm like we did here (Add or skip one frame)
https://github.com/mixxxdj/mixxx/blob/master/src/sounddeviceportaudio.cpp#L404

We may also make the buffer size configurable and add a overflow/underflow counter.

@Tuukka: do you think this will work?

Do you have fun and time to do it?

[Tuukka Pasanen (pasanen-tuukka)]

Hmm.. I can do it but this threading thing in Mixxx is very unknown to me. Is there some FIFO stuff already (I assume there is) or do I use QBuffer?

[Daniel Schürmann (daschuer)]

I think all components are already in place and only need to rearranged a bit.
The only tricky part will to make finally the the syncing work.

You can copy the thread creation from here:
https://github.com/mixxxdj/mixxx/blob/master/src/engine/sidechain/enginesidechain.h#L30
https://github.com/mixxxdj/mixxx/blob/master/src/engine/sidechain/enginesidechain.cpp#L49

The shoutcast thread can run its own while loop like this:
https://github.com/mixxxdj/mixxx/blob/master/src/engine/sidechain/enginesidechain.cpp#L99
and call directly the process() function or better its content, since there is no buffer passed.

The shoudcast thread needs its own m_sampleFifo
https://github.com/mixxxdj/mixxx/blob/master/src/engine/sidechain/enginesidechain.cpp#L77
But there is no wakeAll() call, since the thread usually sleeps at the shout_sync() call.
It should be filled at the EngineMaster the same way. We may consider to fill it conditional if shoutcast is used or not so save some memcpy calls.

Reading the buffer should be done in respect of is content, like done here:
https://github.com/mixxxdj/mixxx/blob/master/src/sounddeviceportaudio.cpp#L404

You may also search GitHub fro reasonable implementations of shoutcast using shout_sync.
I have just found this: https://github.com/rektide/dyne-muse/blob/master/src/shouter.cpp

One approach could be to start the thread on demand once the user enables broadcasting.
Since the thread can now locked infinity at the sockets or shout_sync, we need some management code, that
detects this condition e.g. the m_sampleFifo.
I this case we may terminate() the thread and start a new or much better to investigate if there is a
timeout for shout_sync() shout_write()

Note: This was only a draft directly from my brain, so please consider careful if that is really OK. ;-)

[Tuukka Pasanen (pasanen-tuukka)]

I'll work on this see how this fits to anything.

[Railgun (railgun-michael)]

okay i have the same problems at the moment with streaming at mp3 on an icecast 2 server
so ther eis a bug report with the same problem so i have mark my report as a duplicate.

my System:
Asus Saberthooth Z87
Intel Xeon 1230V3
Artic Freezer 13 Pro
MSI RaDeon HD 270X Gaming 4G
2*8gb Kingston Value
Thermaltake Smart 850W
Windows 7 Proffestional

Peavy PV10 USB
Sound Blaster X-Fi HD

i streaming my mixxx to an icecast2 server with an 192kbps mp3 stream (dosnt matter if i use higher or lower quality)
i have testet the new beta version
Mixxx 1.12 Beta (build r5442) for 64-bit Windows
and the stable version
 Download Mixxx 1.11.0 for 64-bit Windows

so if i stream to the icecast server, the stream hiccups after a while and after this the stream break, so that is buffering,
i cant set the buffer site on my icecast higher (it has alrdy 6 seconds)

i think a better buffer at mixxx would help..
i have saw that i have lost pakages in 15 minutes one or two... so the conection is normaly stable but it lossing one pakage at 15minutes, i tihnk this is the main problem...

i have test the same system and server with the test version of another very expensiv broadcasting tool ( i dont write here a name, becasue it dosnt matter) i can set there a variable buffer time, for the stream software itslef, i i put there a buffersize of 4-6 seconds i can broadcast, without having trouble at the listeners...

[Tuukka Pasanen (pasanen-tuukka)]

Ok thanks for report. Hopefully i'll get testing branch up soon.

[Tuukka Pasanen (pasanen-tuukka)]

Ok now there is pull request on this one. If you have Windows build environment and capability to test this on Windows machine it would nice.

[Sébastien BLAISOT (sblaisot)]

I have a windows build env set up so I can make a build with this patch (although I'm not 100% sure of the quality of my build env), but I don't know how and what to test. Can you give me some instructions ?

[Tuukka Pasanen (pasanen-tuukka)]

Pull request is here to comment: https://github.com/mixxxdj/mixxx/pull/665 and you can clone it from my repo (You'll find it from PR).
After you have clone, compiled and stuff up and running. You need Icecast/Shoutcast server and some other device you can listen this stream (like other laptop, tablet or phone). Then stream to your server and listen weather it buffers all the time or stream just stop but Mixxx still sending it.
If it works with 128 kb/s MP3 then test it with highest 320 and lowest 48. It should work like 2h without any interruptions before you really know it's working. You can also test is you have 44100 and 48000 possibility and with 4 decks all playing together.

If you can use application like mpv or something to determine is stream breaking it would be good. Local icecast server is ok but it would be good to have external. If you need one contact me I'll arrange testing server for you.

[Sébastien BLAISOT (sblaisot)]

ok.

The build is done, you can download the files here if you want to test :
https://owncloud.blaisot.org/index.php/s/cWAwcUVrCN73vGg
I've made either 32 and 64 bits builds, in zip or windows installer.

I don't have an Icecast/Shoutcast server. I will try to install one and test later, but I will be offline for the next week, so if someone with a working test config can give a try with the build I made from your patch it should be faster.

[Hubert Burkert (hubert-gsm)]

Sorry, i have been a bit busy lately so i had no chance to reply.

i can give you a test stream on one of my servers if you want to test something by yourself, just contact me privately.

[Hubert Burkert (hubert-gsm)]

@ Daniel Schürmann

> By the way: Equalizer for the Microphone is Bug #1277274
> @Hubert Burkert: Please add your use case to the Bug. Which EQ do you need. How should the GUI look like?

Basically a simple EQ like any Mixing Console would have, will be fine.
Low / Med / High - so more or less the same that is aready used for the playback decks.

Often Moderators are not spending lots of money on a Microphone, a mixing console or a quallity Mic-Preamp is often just not possible.
also a Compressor / Limmiter, or at least a simple limmiter to avoid clipping would be verry nice to have on the microphone.
...if this is possible it would make mix a realy great piece of software, specially vor broadcasters!

Thanks !

[Hubert Burkert (hubert-gsm)]

@Sébastien BLAISOT (sblaisot)

just testet your build on my Studio setup, so far it looks verry nice.

...but

4 mikrophone inputs look like a real overkill, they are nice to have but, i dont thnink that many users need so many mikrophones.
...but i do like it XD - but it would be nice if it would be possible to Hide "not configured inputs" in the skin ??

the 64bit version of the software does not see my asio devices, the 32 bit version does, and its playing verry nicely. and the controller is working perfect.

Broadcasting just does nothing.
no connection, no feedback, no error message, just nothing.

Greetings, and Thanks for your great work so far :)

Hubert

[Sébastien BLAISOT (sblaisot)]

thanks for the feedback.
Myu build is just a build from the Pull Request trying to solve the broadcasting issue. nothing added, nothing removed.

So, all of your inputs should be made against 1.12 beta (filling a new bug if needed).
and you confirm that proposed patch doesn't solve the broadcasting issue but instead break it completely.

@pasanen-tuukka it seems this one doesn't correct our broadcasting problem :(

[Tuukka Pasanen (pasanen-tuukka)]

Digging this further and can you look at your icecast2 error.log with debug options to see can you see line like: 'source/send_to_listener Client X (Y.Y.Y.Y) has fallen too far behind, removing' when playing with new Mixxx.

[Railgun (railgun-michael)]

I have trat tis Branche now, it works, the stream dies not buffer anymore at a 2hour broadcast.
But i have now a New Problem,
lantency Problem using Windows Direct sound, (if's imposible to usw asio for me)

I dont have acess to the error log off my icast instand because its just rent...

[Railgun (railgun-michael)]

Sry i have forget, i Gould only test wie 192kbs mp3

[Tuukka Pasanen (pasanen-tuukka)]

Are you same Mixxx beta or something else to stream 2 hours?

[Railgun (railgun-michael)]

I had the same Problem sich buffer and hiking stream, noway the stream dosnt buffer anymore but i have noway a Problem Witz latency (i hay tonuse the highest buffer off 96seconds) then it runs...
I have usw the beta Branche postet in this topic.

[Tuukka Pasanen (pasanen-tuukka)]

What happens if you drop buffer to some reasonable rate and are you using somehow slow machine because you should have to buffer that much ever.

[Tuukka Pasanen (pasanen-tuukka)]

And are using 64-bit version or 32-bit version and which Windows?

[Railgun (railgun-michael)]

I have already poster my system in this thread, i using 64bit
my System:
Asus Saberthooth Z87
Intel Xeon 1230V3
Artic Freezer 13 Pro
MSI RaDeon HD 270X Gaming 4G
2*8gb Kingston Value
Thermaltake Smart 850W
Windows 7 Proffestional 64bit

Peavy PV10 USB
Sound Blaster X-Fi HD

[Tuukka Pasanen (pasanen-tuukka)]

Sorry TL;DR problem. That deficiently should have enough power to encode on fly with MP3 192 so you are using 64-bit version which is working as expected besides you are having major latecy.

[Tuukka Pasanen (pasanen-tuukka)]

@hubert-gsm your stream just doesn't work? It doesn't print anything to log?

[Railgun (railgun-michael)]

Yea the higups ect. Is with this Branche fixed for me, now i have only latency problems legt (may create another bug report for this?) (I had this problems sich all Version off mixx)

[Tuukka Pasanen (pasanen-tuukka)]

I think you should make another bug report for it if it's not Shoutcast specific stuff

[Owen Williams (ywwg)]

By latency problems, do you mean the time from when you play sound to the time when you hear it from another computer listening to the radio stream? It's typical for winamp and other streaming listeners to have a 7-10 second buffer. This is very promising feedback!

[Railgun (railgun-michael)]

I had mean the system latency with the beta build

[Owen Williams (ywwg)]

OK If you're having problems with latency and it's the same problems you've been having on other versions of mixxx, I suggest you go to the forums or our IRC channel and ask for some troubleshooting help. Latency problems are not likely to be a bug, since we know Mixxx can still attain <10ms latencies on our developer machines with the new version. It is more likely to be an issue with your system configuration,and the solution may be different settings or a recommendation for different hardware.

http://mixxx.org/forums/viewforum.php?f=3

[Daniel Schürmann (daschuer)]

Tuukka and I have found a possible issues of this bug:
If you have buffer underruns, the soundcard buffer is filled with silence of just played twice.
This does not happen for the sidechain stream. It just consumes the buffer, until it is empty as well and the stream breaks.

[Owen Williams (ywwg)]

ok sounds like we should fix that too. It can be a second PR if it's a clean separation. Thanks for working on this

[Tuukka Pasanen (pasanen-tuukka)]

Now the question is this should we go with this pretty uncute fix for shoutcast (little bit polishing and I have idea how to make out mallocs) or something else. Original bug owner hasn't got fix because it doesn't work for him if I understood right.

[Daniel Schürmann (daschuer)]

I think we are on the right track with moving the broadcasting to a new thread.
What missing is the syncing.

It looks like the libshout does not offer all the primitives to sync the stream in the a low latency context like Mixxx.
This can be solved by an own sync code, almost similar to that what we already have to sync two sound cards.

This in combination with the code already done by Tuukka will make the thing rock solid.

IMHO we need a rock solid solution since this makes a difference from a toy to a product.
I hope I find some time next weekend to do a prototype for the syncing.

The approach will look like that:

* Fill a raw sample buffer, from the engine thread, that is driven by the network clock.
* Add / remove sample in case of buffer underruns, or DAC to Network clock differences.
* Use the shoucast thread to consume the buffer, in reasonable chunks,
* encode the stream and feet it to the server.
* Synced it to the same network clock that used before, but with a reasonable delay that helps to
handle scheduling issues, since the shoutcast thread is not a realtime thread.
(Tuukka has made already a good progress in that)

[Owen Williams (ywwg)]

I do think this is a very similar problem to the issue of two sound cards. Is there any way we can reuse some of that code? Either way I think this design is good. As usual, if you can write the code in a way that makes it easier to test (injectable dependencies, pure functions, clean interface separation) please do.

[Tuukka Pasanen (pasanen-tuukka)]

Code needs rough testing.. Hopefully I'll get setted up Windows 7 machine for that next week so I can test this more easily.

[Owen Williams (ywwg)]

I have a sortof old Windows 7 machine too... now that builds are working again maybe I can get a build triggered for that PR so I can test it too.

[RJ Skerry-Ryan (rryan)]

The build server will now build every commit of @illuusio's branch and upload builds here:
http://downloads.mixxx.org/builds/1.12-broadcast-fixes/release

[Tuukka Pasanen (pasanen-tuukka)]

Ok can anyone now determine is this fixed or not?

[kFYatek (kfyatek)]

OK, so I spent some time checking whether it's fixed and it seems that the biggest problem is gone. I've checked using the 1.12.0-beta1-1.12-shoutcast-fixes-git5533 build for Win64.

However, I've found two smaller bugs related to broadcasting. I'm not sure whether it's related to this patch, or rather some other issues that deserve separate tickets:

- When changing anything in the Preferences window while broadcasting, the broadcast restarts - and this is how it's always worked in Mixxx. However, in this version, the little dialog boxes about the stream having disconnected and reconnected appear, but the actual stream on the server goes off and does not come back. I needed to manually tap Ctrl+L twice to restart broadcasting. I guess a similar problem may occur when the connection is gone for any reason.
- The "Microphone/Talkover Mix" option on the Sound Hardware preferences panel does not work as expected. When set to "Broadcast and Recording only", the microphone signal was not present in the broadcast output. It is present in the recording file, though. So it seems that the wrong signal is used as input for broadcasting.

[Daniel Schürmann (daschuer)]

Thank you for the report.

The "Microphone/Talkover Mix" option issue, is a new one we have to fix.

The preferences issue should be fixed in
http://downloads.mixxx.org/builds/1.12/release/mixxx-1.12.0-beta1-1.12-git5606-release-x64.exe

We have changed the strategy and greyed out the preferences when shout-cast is on air.

[Daniel Schürmann (daschuer)]

I have fixed the microphone issue in
https://github.com/mixxxdj/mixxx/commit/bb1ee0efe0e6ccf6167afe809a818a99c123b66b

It will be available in on of the next builds produced by the build server.

[kFYatek (kfyatek)]

I switched to a recent build of the 1.12 branch, git5614 to be exact, for my production broadcasting usage.

Played two 2-hour shows with it, without any problems. A colleague from my radio did the same (although I'm not sure which exact revision he used) and also played a couple of shows perfectly fine.

So I guess I can confirm that the issue is fixed.

[RJ Skerry-Ryan (rryan)]

With a laptop -> server -> phone
(Mixxx) -> (icecast2) -> (VLC for Android)
all on the same wifi network I still get stream drops about every 5 minutes when streaming with 1.12 HEAD, default icecast2 configuration, and the default VLC configuration.

What triggers it for me is broadcasting from Mixxx with low (~2ms) latency.

[Daniel Schürmann (daschuer)]

Please post your mixxx.log file. What is your device OS setup?
What means the stream drops? How does it continue after dropping?

It might be the case, that @2ms the CPU has not enough resource left to catch up once it falls behind.
An other reason might be the a possible unresolved deadlock in the shoutcast thread.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7295