-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't export audio from master #2457
Comments
@softrabbit I am not able to reproduce this using the latest master (5d3333b). Are you using any special settings for the export? Have you also tried to reproduce this with a complete fresh rebuild (also remove the build directory and let it create from scratch) and a fresh |
I remove my build and target directories all the time, and now I made sure to delete the rc-file too. Seems like the most consistent way for me is a qt5 build, using ALSA out to the actual hardware device. ALSA to the "default" device, i.e. PulseAudio seems to be less problematic. This is a pretty sure way to reproduce on my box:
It might have improved a bit, as the first export seems to succeed more or less always now. On the second attempt I noticed playback is broken as well after the first export, it stays at 0... could be related, maybe something is left in an unexpected state?
|
Been trying to reproduce this. Lots of funky stuff going on:
To fix the reported bug, more investigation is needed into how this situation can come about. Perhaps the cancel-and-reexport bug can be fixed in the same run. As for the deep pulseaudio crash: I've always hated pulseaudio's ALSA emulation 😁, but if it occurs often it may need a look as well. Or maybe it'll disappear after the main bug has been fixed. One can hope. Anyway, I'll see if I can uncover more on this. @softrabbit Could you reproduce the bug with LMMS running in gdb and post the output of |
@softrabbit I tried a bit before that, 9bd4c4f, and it hang on me on onion/export two. I'll try and bisect it again. |
Cool. I'm just busy exporting Onion for the second time in Master... >:-) As you said, fifoWriter. There was a waiting sequence that was removed in f7e5bf4 Edit: Just got a crash though so there may be something else going on there... |
After reverting the line above I can do multiple exports with no problems but lmms will crash on exit, and this only after one export, with messag: |
Someone called for the doctor 💉 😋?
Yeah, adding a timeout argument allows things to continue without the |
Hm... I made PR #2687 which allows playback again after the first export, though it sounds strangely disfigured here. And the second export still hangs, waiting on some mysterious Qt-internal QMutex that can't be traced back to any LMMS code. More investigation work needed, but I need a break. Weird stuff. |
After investigating some more, I have a strong suspicion that this bug is at least partly caused by PulseAudio hijacking the alsa output. When a project is exported, the alsa audio thread fully terminates. PulseAudio seems not to like this. It uses a pthread_mutex_lock that fails an assertion at some thread terminations, but at others, the PulseAudio thread appears to keep running while the alsa thread is already gone, preventing the alsa audio thread from respawning correctly after the export. At any rate, lots and lots of headaches caused by the alsa thread terminating during the export. I'm thinking of solving this by just keeping it running writing zeros. Should be very light on the CPU, and may also prevent future headaches with other sound servers hijacking alsa output. Now how to code this in a way that's not too hacky, hmm... |
To me it sounds like the underlying problem is that the audio export is in some strange way coupled to the audio driver that's used for live playback in the first place. I would have thought that an audio export doesn't use an audio driver (ALSA, Pulse, SDL, etc.) at all and just uses something like a system independent file driver that will collect the audio stream as fast as possible and write the result into a file according to the options that the user has chosen. Is it correct that the export is coupled to the audio driver? And if yes, why is that so? |
what i see is that the project is being silently replayed, not only counter, but even playhead moves during export. That would indicate that two processes take place at the same time? A normal, but silent replay, and a file-handling-process. |
@michaelgregorius The project export uses a special audio interface that writes to a file instead of sending to a soundcard, so that is kind of what you expected. However, that special interface temporarily replaces the normal audio interface, terminating the thread of the normal one. The project renderer attempts to reverse the swap after exporting and restart the thread of the normal audio interface. This gives problems with the alsa audio interface, especially when it's actually backed by PulseAudio. @musikBear It plays as normal indeed, it just replaces the audio driver with a file driver, so to speak. |
@Fastigium That sounds good in principle. Thanks for the insight! |
Ah, the SDL audio interface already does what I propose to do for alsa: write zeros when processing is stopped, keeping its thread alive. I was afraid not stopping the thread might make |
👍 Great job @Fastigium ! |
Testing please! #2687 now fixes the export problem for me. However, I often get distorted sound when I switch projects after exporting. This distorted sound sometimes turns back to normal after a while (a minute or two). More weird stuff. Not sure how critical that is, though. @musikBear Thanks 😊! I was going to say insight alone doesn't fix a problem, but it's an essential step toward a fix, so I'll take the compliment and be happy with it 🍻 |
I'm testing this now with multiple exports and switching projects in between. Five different projects and counting, this now works. I had a project hanging on me but that's hardly related.
I haven't seen the noise you refer to but I've had it before, properly scrambled sound that is, and I think it's pretty much a known issue but I can't find the report for it right now. |
I did some extensive testing with various backends for this bug report, not sure if the symptoms are similar or not... Edit: Also #158 #2582 |
@zonkmachine Thanks for the testing! @tresf Thanks, that's some interesting reading! Places things in perspective. @softrabbit If you have the time, I'd love to know if #2687 fixes this bug for you as well! |
Probably unrelated, but some interesting output from
|
@tresf Thanks for the heads-up! I've looked into it, but that use of strcpy is actually fine. No user input involved, so no chance of overflow or overallocation. |
👍 |
@Fastigium: well done, #2687 seems to fix this issue. Haven't extensively tried to break it yet, but exported some 5 times in a row without LMMS hanging or breaking playback 👍 |
@softrabbit Thanks for testing! I'll close this issue when #2687 is merged. In the mean time, a comment by Wallacoloo gives me pause. #2687 would introduce another such member that technically requires synchronization. Testing so far hasn't turned up any problems, but since these source files are compiled with C++11 enabled any compiler is free to optimize |
Welp, what a mess! I've been investigating the issue even more, and have reached this conclusion: a small redesign is needed in how LMMS stops processing audio. Let me explain:
What I would want to happen is this:
Also, there are lots of benign races in the code (unsynchronized booleans used for signalling threads to stop; no, declaring them TL;DR: Some LMMS code sucks right now; I want to improve it but making the right choices is hard 😓 |
Sorry for spamming this bug, but thinking "aloud" helps my thought process, and this gives other people with thoughts on the matter a chance to chime in 😊 My vision for a redesign is somewhat hampered by an interesting property of the fifoBuffer: it blocks both when reading stops too early or too late and when writing stops too early or too late. Therefore, any synchronization mechanism that circumvents the fifoBuffer is prone to cause deadlocks on stopping the processing of audio. In other words, there's a reason that audio interfaces used to be stopped by a signal transported by the fifoBuffer itself: it guaranteed that the audio device would stop processing at exactly the right moment. Also, at default settings, the fifoBuffer only holds a single sampleframe, so the delay on stopping the processing of audio is negligible (5.8 ms). At any rate, the pre-f7e5bf4 way isn't as bad as I thought. It is confusing, however, that calling So if I were to revert f7e5bf4 and 98346f7, modify Boy, that almost sounds to good to be true, I really hope I understand it correctly now 😝. I'll mull over it for a little while longer, and if it still seems like a good idea, I'll make another PR. The LMMS code base is frighteningly complex sometimes 😰 |
What change occurred to make this undesirable (can/should we go back to that original signal method)?
Yeah that's quite confusing indeed. Perhaps |
It is only undesirable because the whole existing fifoBuffer needs to be processed before the signal reaches the AudioDevice. But I called it undesirable before I learned that by default, the fifoBuffer holds a whopping 5.8 ms of samples 😁 As for going back to the original method, I was proposing to do that. "So if I were to revert f7e5bf4 and 98346f7, modify
Could you expound on that a little? I'm not sure what you mean now 😅 |
I was trying to help come up with a new name, that's all. 👍 |
Ok, so on the current master, this issue is fixed for me on ALSA and SDL backends. @jasp00's recent PR's probably fixed this. I do however get a crash on exporting with the Jack backend, but that's a different issue. @softrabbit could you test out to confirm this? I'll make an new issue for the Jack crash. |
Can anyone still reproduce this bug on current master, or is it fixed? |
I can export projects without freeze, so I think this is fixed. |
Just a data point on this for Mac OS X 10.8.x:
|
@follower This was fixed after 1.2.0-RC1. You need to test the latest source or the next RC when it's available. |
Rendering audio to files is broken in master, the progress bar sticks at 0 and the GUI freezes. Tested with
Skiessi-Onion.mmpz
and some others, 64-bit builds fail but on my 32-bit system I get one successful export and the second one in the same LMMS instance freezes.Git bisect points to 8b65ae3 but I might've screwed something up, as that commit looks pretty unlikely to cause this.
The text was updated successfully, but these errors were encountered: