#90
- Created on2009-08-23 16:51
- Reported by
- StatusTest
- PriorityHigh (2)
- Assigned to-
- Milestone
- Plan Level-
- Due Date-
recording bug with new versions of alsa on linux
the recording works at first and stops working after a random time. The buffer content seems not to be cleared, the note that was sung when the bug appears is sung until the recording is stopped. The oscilloscope shows the same line over and over. (the line that was shown when the bug appears.
Some further (german) descriptions:
link
Some further (german) descriptions:
link
Leave a comment
on 2010-01-13 02:13 *
By Whiteshark
have to test if portmixer fixes this issue
also have to test same configuration with audacity
also have to test same configuration with audacity
on 2010-03-30 12:17 *
By Whiteshark
audacity has the same issues
https://bugs.launchpad.net/ubuntu/+source/portaudio19/+bug/347319
seems not to be our fault
https://bugs.launchpad.net/ubuntu/+source/portaudio19/+bug/347319
seems not to be our fault
please test w/ current portaudio trunk
seams to be fixed
seams to be fixed
A bug in Pulseaudio is possible too. People report USDX to work after updating it.
If it is a portaudio bug: the next ubuntu version 10.4 (lucid) will still be delivered with the same buggy version (19+svn20090620).
Appart from that I looked at AudioIO.cpp of Audacity's trunk as it captures mic input correctly with its patched and statically linked portaudio version. Linking USDX against that version still does not fix the "mic gets stuck" bug.
The bug seems to be related to the portaudio input latency settings used in USDX. We always use the defaultLowInputLatency (approx. 15ms) value detected by portaudio. Audacity instead uses defaultHighInputLatency (approx. 45ms) if software playthrough is on and a (hard-coded) latency of 100ms for normal recording (w/o playthrough).
It seems portaudio gets stuck while processing mic-input if the callback does not return in time. If the latency is x ms and the callback needs more time, portaudio (or maybe pulseaudio) will get stuck. At the moment the mic input data is copied multiple times in the callback (even with passthrough disabled), maybe that is already too slow.
I changed the default of USDX to defaultHighInputLatency (causes bigger delays for playthrough) and added a "latency" device option to config.ini in case this value is still not working (as for me). Setting the latency manually to 100 (ms) in the config.ini fixes this bug. With this setting mic input is very stable. With defaultHighInputLatency the mic-input still gets stuck after a few seconds.
In addition the device test is always performed with at least 100ms latency so we do not remove working devices that might have problems with too low latencys.
Conclusion:
If this bug occurs, try to set the new latency option in config.ini to 100 for the non-working device.
If it is a portaudio bug: the next ubuntu version 10.4 (lucid) will still be delivered with the same buggy version (19+svn20090620).
Appart from that I looked at AudioIO.cpp of Audacity's trunk as it captures mic input correctly with its patched and statically linked portaudio version. Linking USDX against that version still does not fix the "mic gets stuck" bug.
The bug seems to be related to the portaudio input latency settings used in USDX. We always use the defaultLowInputLatency (approx. 15ms) value detected by portaudio. Audacity instead uses defaultHighInputLatency (approx. 45ms) if software playthrough is on and a (hard-coded) latency of 100ms for normal recording (w/o playthrough).
It seems portaudio gets stuck while processing mic-input if the callback does not return in time. If the latency is x ms and the callback needs more time, portaudio (or maybe pulseaudio) will get stuck. At the moment the mic input data is copied multiple times in the callback (even with passthrough disabled), maybe that is already too slow.
I changed the default of USDX to defaultHighInputLatency (causes bigger delays for playthrough) and added a "latency" device option to config.ini in case this value is still not working (as for me). Setting the latency manually to 100 (ms) in the config.ini fixes this bug. With this setting mic input is very stable. With defaultHighInputLatency the mic-input still gets stuck after a few seconds.
In addition the device test is always performed with at least 100ms latency so we do not remove working devices that might have problems with too low latencys.
Conclusion:
If this bug occurs, try to set the new latency option in config.ini to 100 for the non-working device.
> In addition the device test is always performed with at least 100ms latency so we do not remove working devices that might have problems with too low latencys.
This means: it does NOW test devices with at least 100ms. Previously defaultLowInputLatency was used for this and some people reported that no device was left in the device option (in contrast to audacity) as all devices were removed by USDX and marked as non-working in the Error.log.
This means: it does NOW test devices with at least 100ms. Previously defaultLowInputLatency was used for this and some people reported that no device was left in the device option (in contrast to audacity) as all devices were removed by USDX and marked as non-working in the Error.log.