Multichannel-Recording gets out-of-sync over time about mumble

[hacst]

That is interesting. We'll have to try to reproduce that to make sure but - from what I remember of the code - it is very well possible that loss might cause syncing issues we did not consider.

This might be a duplicate of https://sourceforge.net/p/mumble/bugs/846/

In https://sourceforge.net/p/mumble/bugs/846/ they say explicitly "Recording in .wav does not produce this problem.". That's why I opened up a new ticket. I didn't check for error in the compressed formats though, since I guess it'll make things even more complicated.

I did some further investigations. When I add 2-3 seconds of silence (using Audacity) right after the garbled voice part in the 30th minute, the streams seem to be in-sync until the end.

This is still happening with the latest version of the client app. I also have this issue when recording in wav, but cannot yet confirm it happening in any other audio format. However I don't have any further information regarding UDP transmission errors.

Has there been any progress on this issue?

[hacst]

We are currently testing a branch that should fix this problem for 1.2.5. Once it hits the snapshots (should be soonish) I'll updated this issue. Here the basic description of the underlying issue:

"Previously the wall clock was used to align speakers. As this didn't
allow for reliable detection of silence between outputs a heuristic
was used which only started adding silence after 100ms.

This patch makes the mixer keep track of the absolute number of samples
requested from it. This number is then forwarded to the recorder with
each addBuffer to allow for sample precise alignment.

To get the absolute sample number when starting the recording a thread-safe
way to retrieve this counter from the outside was added using a new
mixer lock."

If you want to track development or perform early testing feel free to take a look at the branch at https://github.com/dD0T/mumble/tree/recorderfix

[notthetup]

Awesome! Will test out the branch.

Quick question, will ALL speakers need to have the patch? Or will I be able to test out with just the mixer and recorder having it?

[hacst]

@notthetup Only the one recording will need a patched version. Unfortunately the approach I took in the branch isn't suited to solve the issue for all supported audio backends. I started of some wrong assumptions and didn't yet get to re-work it.I'll post an update on this issue once I do. Sorry for the additional delays.

[notthetup]

👍

[hacst]

@notthetup I just merged my branch which hopefully should fix this issue. I and Natenom tested it and it looked fine with multiple hour recordings. Snapshots are building currently (should be 1.2.5-240-gea165cd). Would be great if you could check to make sure this fixes your issues.

[notthetup]

Thanks! Will test it out!

[notthetup]

OK. Before I can setup to test a long recording, I was editing the last 1hr+ recording which I did yesterday. I had moved up my mumble client (on OSX 10.9.1) to 1.2.5 (stable) before the recording.

Surprisingly even after an hour, I don't see ANY drift in the recording! Not sure if something else in 1.2.5 fixed it for me, or if it was a fluke. But just an interesting data-point for observation. :)

[hacst]

1.2.5 doesn't have any changes compared to 1.2.4 apart from two security fixes so they wouldn't affect recording. Maybe you got lucky ;)

[hacst]

I'm closing this in the assumption that the issue is resolved. Please reopen if this isn't the case.

[notthetup]

Appologies.. I didn't get the time to try out a long recording.. I have one scheduled on Saturday.. I will let you know after.

[notthetup]

Managed to test with 1.2.5-240-gea165cd on OSX 10.9, for a 1hr10mins recording on. Perfect!! No drift!! Thanks for your patch!

[SpAMCAN]

Feel free to reopen this. Literally no idea why, what causes it, or how it happens, but we are getting huge desync issues while recording. We can't figure out exactly why it occurs, but it does, even when recording in WAV (the issue is less when recording in WAV, but it's still there).

[Natenom]

@SpAMCAN Which Mumble version do you use?

[CataclysmZA]

I'd like this to be re-opened. I see exactly the same audio drift issues even with WAV recording and it drives me nuts. There's no rhyme or reason for it as far as I've been able to investigate and with recording under any other file format, especially my tests with OGG, the desync issues cause the recording times to be out as much as 5 seconds. I have seen very few people raise this bug up as an issue they suffer from, which leads me to believe that most people aren't recording in multi-channel mode and if anyone is suffering from issues stemming from this, it's not something they're taking time to troubleshoot and fix.

[CataclysmZA]

I'm on Windows 8.1 Professional, Mumble 1.2.8. I'm recording on multi-channel with WAV and editing in Audacity. I have a triple-core processor, 8GB RAM and I'm using a pair of USB microphones for the recording on my side along with a Creative PCI sound card with updated drivers. Internet-wise I'm sitting at 200KB/s down and 40KB/s up. Most of the time, I have five or less people in a podcast that I record, with no more than three people talking at the same time.

I'm also not sure if the fixes for the audio drift ever landed up into the stable channel for Mumble. I see there's still a recorderfix branch, but I'm not sure if this would help my problem.

[SuperTux88]

@CataclysmZA It's only fixed in the 1.3.0 snapshots and not in stable.

[CataclysmZA]

Really? Damn. Reading this thread I had hoped it was put in earlier this year. So where do I go to download the snapshot and get to testing it?

[SuperTux88]

You can download the snapshots from the mumble-wiki: http://wiki.mumble.info/wiki/Main_Page under "Development Snapshot" :)

[CataclysmZA]

Ah! Well that's easy enough. mkrautz, I'd like to request that you leave this bug tracker open, please. I'll provide feedback throughout the weekend and if I'm happy, I'll request that it be closed again.

[hacst]

@CataclysmZA Any updates? I'm pretty sure I had this resolved.

[CataclysmZA]

I believe its fixed, the real test comes tomorrow to see how it holds up. When I import the audio streams into Audacity it seems to be perfectly in sync, but the files themselves are of different sizes and slightly varying in length. If Mumble saves audio to my drive in chunks every now and then that might explain it, but so far I have no problems. Please close! And I hope to see this go into the stable channel very soon.

Also, I noticed that the recorder timer isn't displayed properly when I start recording. It isn't much of a dealbreaker, but I prefer to add in notes as to when topics change as we go through the podcast, not after because that takes a lot of time.

Keep up the good work. :)

[hacst]

Just out of curiosity: What podcast are you recording? ;) Always looking for additions to my list.

Looking forward to your feedback.

[CataclysmZA]

I run the NAG Online gaming podcast, we're based in South Africa. We're only ten episodes in and doing everything we can to improve without spending silly amounts of money. Its a small audience, but it's growing slowly. For now we're figuring out the basics and getting the content, how we sound and run-time right before we do the really complicated stuff like iTunes publishing and the like.

http://www.nag.co.za/tag/nag-podcast/

[notthetup]

OT: iTunes publishing is easy. Just make an RSS feed. Your CMS might be doing that already.

You'll also need to have 1400x1400 album art embedded in your audio files.

[CataclysmZA]

Well, there doesn't seem to be any audio drift anymore, but I'd like to submit a bug for my Singstar microphones. They work perfectly well in dual-channel with the stable version of Mumble, but the dev snapshot would either not pick them up, or it would only see one channel despite my changing sound options and running through the audio wizard multiple times.

Good stuff!

[hacst]

Thanks for reporting back. Feel free to open a new issue for the microphone problems. I'll close this one.

[rtrind]

I'd like to get this reopened. I am the "technical guy" for a small podcast in Brazil and since we discovered mumble it was a pleasure using the record feature to skip using Skype audio and individual local recordings.

But we are having serious desync issues all the time. We were using a 1.3.0 snapshot version on a local server at my house. After 20 minutes of recording, the audio tracks start to drift and they continue to drift until the end of the tracks.

We all use continuous mode all the time because there is always a popping sound on the beginning of each voice capture (not always, but frequent enough we notice it, we will open another ticket for this after the recording issue is solved). Some users were having audio aggressive delays during the recordings (because of the low quality brazilian internet, reaching 4000 latency), so we put the murmur server on the Amazon EC2, Sao Paulo (very low latency, 1520ms). This solved most of the delays while talking with 46 clients in continuous mode.

Even so, the recording does not reflect the audio we hear while live, the tracks are still drifting. One user was recording on wav format and me on flac. Both representations have the drift.

Right now the murmur server is using version 1.3.0540gedd5509 on a Ubuntu 14.04.2 LTS, hosted on Amazon EC2. The live session goes perfect, without any problems (except for some specific problems with some users), but the recording always suffers. We believe most of the clients are up to date, but we never checked one by one.

I don't know what you guys need us to deliver for this analysis to be performed. Feel free to ask anything and I will help as best as I can.

[hacst]

The important part for recording is the client. What client version is the recording party running? It needs to be a 1.3.0 snapshot.

[rtrind]

It makes sense. The recorders are myself and the podcast editor. Both always update to the latest snapshot when prompted by the software, so we are always using the latest one. Last recording we were at the same gedd5509 version on both clients. Some other participants in the call could be using other clients, we didn't checked.

[hacst]

I guess the issue isn't resolved for all cases after all then :( As it seems to be an edge case I opened #1617 to track this separately.