Created attachment 173816 [details] logs compressed At the beginning - audio recording on other devices (internal microphone, usb headset with microphone) works OK. There is issue with one USB microphone ("pro"). - plug device into USB - device is discovered - start kdenlive, enter settings, set recording to this device (is detected), set 44k1 and 1-channel (mono) - go to timeline, enable sound monitoring for recording, soundbar displays correctly sound level from this microphone - clik on the record button, it is enabled, automatically in the project bin displays the error that CaptureXXXX.wav cannot be loaded I've checked all setting variations (1/2 channels, 44k1, 48k). In Audacity recording with this device works OK. In the log one can see error: qt.multimedia.ffmpeg.encoder: Stream initialization error: "Audio device has invalid preferred format" !!!!!!!!!!!!!!!! ERROR : QMediarecorder - Capture failed Something is wrong with setting recording format during initialization. In the attachment: - lsusb of this device - it is branded "Mozos", but it is generic "chinese" microphone platform with generic USB interface - dmesg of this device during connection - kdenlive log with selected behaviour (two consecutive clicks on the record button)
I'm also running into this on version 24.12.2. Looks like bug #496211 may be a duplicate of this one.
Additionally I might add, that this exact device was recording correctly with previous version of Kdenlive. Don't know exact numbers, but before the recording architecture overhaul - from Qt5 to Qt6 AFAIK (sorry for this shortcut). Firstly when early versions of Kdenlive with Qt6 was released the recording in-app was postponed to next versions. And next when it returns, the recording hits this bug. I hope this helps a bit. I can try to fix/fiddle with it (can compile Kdenlive) and provide some tips to correctly fix it, but if someone could pinpoint area in the code which can be responsible for this. I think something with creating audio recorder objects and audio format. Sorry. Not an expert with Qt :) and don't have much time for digging it by myself.
Thank you for reporting. For me it looks like your microphone is connected to the graphic card and so hardware accelerated. Try the following: Update your graphic card driver Download the latest official AppImage https://kdenlive.org/en/download/, this to avoid any packaging issue Try again If the issue still happen try your microphone on a "normal" USB connection on your computer
Hi, Sorry, don't know exactly what do you mean about hardware acceleration of this microphone (first heard of). You mean that in the graphic card has usb/xlr/jack connector ? Using laptop and long time no pc/desktop user :) It is/was always connected via USB bus/cable to the computer. Using ubuntu 24.04 and using standard intel+nvidia drivers. How can I find if this audio connection is hardware accelerated ?
(In reply to emohr from comment #3) > Thank you for reporting. > For me it looks like your microphone is connected to the graphic card and so > hardware accelerated. > > Try the following: > Update your graphic card driver > Download the latest official AppImage https://kdenlive.org/en/download/, > this to avoid any packaging issue > Try again > > If the issue still happen try your microphone on a "normal" USB connection > on your computer I'm seeing this error on my computer which is a regular desktop computer with an Asus PRIME X670-P motherboard, and the USB microphone connected directly to one of the normal motherboard USB connectors.
For what it's worth, I was able to work around this issue by adding the microphone as a JACK client using alsa_in, selecting the microphone as the default source in PipeWire, routing the capture channels from the microphone JACK device to the capture_FL and capture_FL inputs on the PipeWire JACK device, and finally selecting "JACK Source" as the capture device in Kdenlive. I'm not sure if all of these steps are necessary, and "JACK Source" overall seems like a weird device option to have for me given that Kdenlive seemingly doesn't add its own JACK device which you can route stuff to, but I was able to successfully record sound from the microphone using this method at least.
We just fixed some similar audio recording crash. Please try with the latest Kdenlive daily build to see if the crash still appears: https://kdenlive.org/en/download/
Created attachment 188058 [details] Test results from 2025-12-29. Screenshots, log and recorded audio.
(In reply to emohr from comment #7) > We just fixed some similar audio recording crash. Please try with the latest > Kdenlive daily build to see if the crash still appears: > https://kdenlive.org/en/download/ I've tested this. Not crashing. Still something is wrong with the final encoding (?) of the file. I've attached zip file with results and screenshots. What i've done: - started nightly version - created new project - go to config and check, that the appropriate microphone is selected - go to edit workbench, select recording monitoring on a1 track - i can see the audio monitor and the output is correct e.g. the sound level is working as expected - click record button - i can see the waveform is correctly with the recording sounds (also the length of the recording) - i click again record button, recordings stops and (two versions): 1) - nothing is inserted into the project timeline (on a1 track) but in the project bin i can see recordings but playing it gives garbage 2) - recording was inserted into the timeline and into the project bin, but the recording length in the project timeline is much shorter than the monitored band (during recording) - when playing we see that the recording is shorter than expected, when playing i can see only some rubbish. Tried to slow it down (in audacity) but it does not give anything meaningful In the attachment - some screenshots, full log from the console and last recorded audio (mainly speaking "testing" during recording)
Git commit aac7d5c3349003d17f911028d529fb0c00988d65 by Jean-Baptiste Mardelle. Committed on 30/12/2025 at 06:33. Pushed by mardelle into branch 'master'. Audio capture: minor cleanup, ensure we use a channel count/sample rate compatible with mic. M +40 -66 src/capture/mediacapture.cpp M +4 -1 src/capture/mediacapture.h https://invent.kde.org/multimedia/kdenlive/-/commit/aac7d5c3349003d17f911028d529fb0c00988d65
Please try again with the latest Kdenlive daily build to see if the issue still appears: https://kdenlive.org/en/download/
Created attachment 188074 [details] Test results from 2025-12-30
So looking at the uploaded results, if I understand correctly, the recording usually works on the first attempt, but stopping and recording again sometimes produces a corrupted recording ?
(In reply to Jean-Baptiste Mardelle from comment #13) > So looking at the uploaded results, if I understand correctly, the recording > usually works on the first attempt, but stopping and recording again > sometimes produces a corrupted recording ? Strange, i've attached file (sorry, cannot upload and comment at the same time) and create lengthy response (send minutes ago) but it is not showing. Strange. yes, but the first one is also somewhat messed. The audacity recordings have similar lenght/tempo of next numbers spoken, but the first recording is almost ok, but when you play it you can hear that some numbers as spoken much faster than other. it was recorded with the same tempo/tone. Strange :)
(In reply to Slawek Mikula from comment #14) > (In reply to Jean-Baptiste Mardelle from comment #13) > > So looking at the uploaded results, if I understand correctly, the recording > > usually works on the first attempt, but stopping and recording again > > sometimes produces a corrupted recording ? > > Strange, i've attached file (sorry, cannot upload and comment at the same > time) and create lengthy response (send minutes ago) but it is not showing. > Strange. > > yes, but the first one is also somewhat messed. The audacity recordings have > similar lenght/tempo of next numbers spoken, but the first recording is > almost ok, but when you play it you can hear that some numbers as spoken > much faster than other. it was recorded with the same tempo/tone. Strange :) Exactly you can hear it in capture-0000.wav in "second_attempt" folder. It was spoken the same as the "test_audacity2.wav". Was trying to keep 10s recording and the same texts. From kdenlive it is faster and hearable most at the "two" number.
Git commit 595009eec7ae37ff695adde0b798e367d3ceff21 by Jean-Baptiste Mardelle. Committed on 30/12/2025 at 17:24. Pushed by mardelle into branch 'release/25.12'. Audio capture: minor cleanup, ensure we use a channel count/sample rate compatible with mic. M +40 -66 src/capture/mediacapture.cpp M +4 -1 src/capture/mediacapture.h https://invent.kde.org/multimedia/kdenlive/-/commit/595009eec7ae37ff695adde0b798e367d3ceff21