Multichannel-Recording gets out-of-sync over time #9

Author

Owner

@mumble-voip commented on GitHub (Feb 21, 2013):

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.

@mumble-voip commented on GitHub (Feb 21, 2013): 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.

deekerman commented

Author

Owner

@mumble-voip commented on GitHub (Oct 31, 2013):

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?

@mumble-voip commented on GitHub (Oct 31, 2013): 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?

deekerman commented

Author

Owner

@hacst commented on GitHub (Nov 7, 2013):

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

@hacst commented on GitHub (Nov 7, 2013): 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

deekerman commented

Author

Owner

@notthetup commented on GitHub (Nov 26, 2013):

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?

@notthetup commented on GitHub (Nov 26, 2013): 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?

deekerman commented

Author

Owner

@hacst commented on GitHub (Nov 26, 2013):

@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.

@hacst commented on GitHub (Nov 26, 2013): @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.

deekerman commented

Author

Owner

@notthetup commented on GitHub (Nov 30, 2013):

👍

@notthetup commented on GitHub (Nov 30, 2013): :+1:

deekerman commented

Author

Owner

@hacst commented on GitHub (Feb 13, 2014):

@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.

@hacst commented on GitHub (Feb 13, 2014): @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.

deekerman commented

Author

Owner

@notthetup commented on GitHub (Feb 15, 2014):

Thanks! Will test it out!

@notthetup commented on GitHub (Feb 15, 2014): Thanks! Will test it out!

deekerman commented

Author

Owner

@notthetup commented on GitHub (Feb 15, 2014):

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. :)

@notthetup commented on GitHub (Feb 15, 2014): 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. :)

deekerman commented

Author

Owner

@hacst commented on GitHub (Feb 16, 2014):

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 commented on GitHub (Feb 16, 2014): 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 ;)

deekerman commented

Author

Owner

@hacst commented on GitHub (Feb 22, 2014):

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

@hacst commented on GitHub (Feb 22, 2014): I'm closing this in the assumption that the issue is resolved. Please reopen if this isn't the case.

deekerman commented

Author

Owner

@notthetup commented on GitHub (Feb 23, 2014):

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 commented on GitHub (Feb 23, 2014): 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.

deekerman commented

Author

Owner

@notthetup commented on GitHub (Mar 1, 2014):

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!

@notthetup commented on GitHub (Mar 1, 2014): 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!

deekerman commented

Author

Owner

@SpAMCAN commented on GitHub (Jun 4, 2014):

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).

@SpAMCAN commented on GitHub (Jun 4, 2014): 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).

deekerman commented

Author

Owner

@Natenom commented on GitHub (Jun 4, 2014):

@SpAMCAN Which Mumble version do you use?

@Natenom commented on GitHub (Jun 4, 2014): @SpAMCAN Which Mumble version do you use?

deekerman commented

Author

Owner

@CataclysmZA commented on GitHub (Sep 26, 2014):

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 commented on GitHub (Sep 26, 2014): 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.

deekerman commented

Author

Owner

@CataclysmZA commented on GitHub (Sep 26, 2014):

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.

@CataclysmZA commented on GitHub (Sep 26, 2014): 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.

deekerman commented

Author

Owner

@SuperTux88 commented on GitHub (Sep 26, 2014):

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

@SuperTux88 commented on GitHub (Sep 26, 2014): @CataclysmZA It's only fixed in the 1.3.0 snapshots and not in stable.

deekerman commented

Author

Owner

@CataclysmZA commented on GitHub (Sep 26, 2014):

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?

@CataclysmZA commented on GitHub (Sep 26, 2014): 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?

deekerman commented

Author

Owner

@SuperTux88 commented on GitHub (Sep 26, 2014):

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

@SuperTux88 commented on GitHub (Sep 26, 2014): You can download the snapshots from the mumble-wiki: http://wiki.mumble.info/wiki/Main_Page under "Development Snapshot" :)

deekerman commented

2026-02-20 19:09:41 -05:00

Author

Owner

@CataclysmZA commented on GitHub (Sep 26, 2014):

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.

@CataclysmZA commented on GitHub (Sep 26, 2014): 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.

deekerman commented

Author

Owner

@hacst commented on GitHub (Sep 30, 2014):

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

@hacst commented on GitHub (Sep 30, 2014): @CataclysmZA Any updates? I'm pretty sure I had this resolved.

deekerman commented

2026-02-20 19:09:41 -05:00

Author

Owner

@CataclysmZA commented on GitHub (Sep 30, 2014):

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. :)

@CataclysmZA commented on GitHub (Sep 30, 2014): 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. :)

deekerman commented

2026-02-20 19:09:41 -05:00

Author

Owner

@hacst commented on GitHub (Sep 30, 2014):

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

Looking forward to your feedback.

@hacst commented on GitHub (Sep 30, 2014): Just out of curiosity: What podcast are you recording? ;) Always looking for additions to my list. Looking forward to your feedback.

deekerman commented

2026-02-20 19:09:42 -05:00

Author

Owner

@CataclysmZA commented on GitHub (Oct 1, 2014):

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/

@CataclysmZA commented on GitHub (Oct 1, 2014): 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/

deekerman commented

2026-02-20 19:09:42 -05:00

Author

Owner

@notthetup commented on GitHub (Oct 2, 2014):

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.

@notthetup commented on GitHub (Oct 2, 2014): 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.

deekerman commented

Author

Owner

@CataclysmZA commented on GitHub (Oct 2, 2014):

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!

@CataclysmZA commented on GitHub (Oct 2, 2014): 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!

deekerman commented

Author

Owner

@hacst commented on GitHub (Oct 2, 2014):

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

@hacst commented on GitHub (Oct 2, 2014): Thanks for reporting back. Feel free to open a new issue for the microphone problems. I'll close this one.

deekerman commented

Author

Owner

@rtrind commented on GitHub (Mar 27, 2015):

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, 15~~20ms). This solved most of the delays while talking with 4~~6 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.0~~540~~gedd5509 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.

@rtrind commented on GitHub (Mar 27, 2015): 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, 15~20ms). This solved most of the delays while talking with 4~6 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.0~540~gedd5509 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.

deekerman commented

Author

Owner

@hacst commented on GitHub (Mar 27, 2015):

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.

@hacst commented on GitHub (Mar 27, 2015): 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.

deekerman commented