Thread: [Audacity-devel] Audacity stops recording from USB audio source when unsupported sample rate select
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Michael S. <msc...@gm...> - 2009-12-27 18:45:41
|
https://bugzilla.redhat.com/550730 | When recording from my USB web cam mic, if I select a sample rate not | supported by the source, audacity records a fraction of a second of audio, | and then stops. The progress bar keeps moving, but no new data shows up. | | My card only supports 16kHz. If I select 16kHz in audacity recording works | fine, but if I select a different sample rate I get the behavior described | above. As I understand it, Audacity should normally resample on-the-fly. Is this known to be broken? |
From: Michael S. <msc...@gm...> - 2009-12-28 00:54:46
|
On Sun, 27 Dec 2009 19:45:23 +0100, I wrote: > https://bugzilla.redhat.com/550730 > > | When recording from my USB web cam mic, if I select a sample rate not > | supported by the source, audacity records a fraction of a second of audio, > | and then stops. The progress bar keeps moving, but no new data shows up. > | > | My card only supports 16kHz. If I select 16kHz in audacity recording works > | fine, but if I select a different sample rate I get the behavior described > | above. > > As I understand it, Audacity should normally resample on-the-fly. > Is this known to be broken? Probably not ;) and here's the rationale: This is reproducible also with ordinary audio sources. Audacity resamples on-the-fly if the project rate doesn't match the audio input rate. Fedora's build of Audacity uses libsamplerate 0.1.7 whereas Audacity by default would use libresample 0.1.3 (and also contains an optional copy of that library source code). (the background is explained here: http://wiki.audacityteam.org/index.php?title=Libresample ) Building with the included libresample, the problem is _not_ reproducible. Building with the system's libresample, the build fails early. Perhaps just because of a broken pkg-config file. This will need a fix in that package or a temporary work-around in our audacity package in case we would like to switch to libresample. When using libsamplerate, the recording stops early because Audacity's resampling code sets an "end of input" flag for all sample input buffers. If not doing that, the problem disappears here. [...] Is there a recommendation on whether to prefer libresample over libsamplerate or vice versa? The latter seems slower to me. And if official builds of Audacity use libresample, I would feel better if Fedora's package would do the same. |
From: Richard A. <ri...@au...> - 2009-12-28 15:27:09
|
On Mon, 2009-12-28 at 01:54 +0100, Michael Schwendt wrote: > On Sun, 27 Dec 2009 19:45:23 +0100, I wrote: > > As I understand it, Audacity should normally resample on-the-fly. > > Is this known to be broken? > > Probably not ;) and here's the rationale: > > This is reproducible also with ordinary audio sources. > > Audacity resamples on-the-fly if the project rate doesn't match the audio > input rate. Fedora's build of Audacity uses libsamplerate 0.1.7 whereas > Audacity by default would use libresample 0.1.3 (and also contains an > optional copy of that library source code). (the background is explained > here: http://wiki.audacityteam.org/index.php?title=Libresample ) > > Building with the included libresample, the problem is _not_ reproducible. > > Building with the system's libresample, the build fails early. Perhaps > just because of a broken pkg-config file. This will need a fix in that > package or a temporary work-around in our audacity package in case we > would like to switch to libresample. What system package of libresample? As the wiki page implies (but didn't make clear, I've fixed it), the libresample in Audacity CVS is "internal" to Audacity, based of the Stanford code. There seem to be a number of other forks of the Stanford code, the Audacity code and probably other things out there - I have no idea what your system package might be, except probably not the same as what Audacity is using. Either way I (we) disclaim responsibility for any copy of "libresample" outside the Audacity source tree, and don't test with any of them. I don't think external libresample is supported by our configure script - certainly I've never tested it ... > When using libsamplerate, the recording stops early because Audacity's > resampling code sets an "end of input" flag for all sample input > buffers. If not doing that, the problem disappears here. Sounds like there may be a genuine bug here, which would of course remain regardless of using internal / external libsamplerate. I think we need to split this into two different bugs at this point. > Is there a recommendation on whether to prefer libresample over libsamplerate > or vice versa? The latter seems slower to me. And if official builds of > Audacity use libresample, I would feel better if Fedora's package would do > the same. All the Audacity released binaries use libresample to avoid licensing hassle (especially as there are closed-source VAMP plug-ins available for Linux now). If the user doesn't specify a preference when running configure it selects the internal libresample, so implicitly that's what we recommend. We are still fixing libsamplerate bugs when they are reported, not least because it's probably a better resampling library (it's certainly a more flexible one), but I'm sure not many people use it. Gentoo's ebuild supports both, but defaults to libresample unless the user sets a flag to use libsamplerate. Richard |
From: Benjamin D. <bd...@ub...> - 2009-12-28 17:48:37
|
Am Montag, den 28.12.2009, 15:26 +0000 schrieb Richard Ash: > We are still fixing libsamplerate bugs when they are reported, not least > because it's probably a better resampling library (it's certainly a more > flexible one), but I'm sure not many people use it. Gentoo's ebuild > supports both, but defaults to libresample unless the user sets a flag > to use libsamplerate. Debian/Ubuntu uses libsamplerate, too. -- Benjamin Drung Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org) |
From: Michael S. <msc...@gm...> - 2009-12-30 22:40:29
|
On Mon, 28 Dec 2009 15:26:51 +0000, Richard wrote: > > Building with the included libresample, the problem is _not_ reproducible. > > > > Building with the system's libresample, the build fails early. Perhaps > > just because of a broken pkg-config file. This will need a fix in that > > package or a temporary work-around in our audacity package in case we > > would like to switch to libresample. > > What system package of libresample? Fedora's. I've filed a bug about that: http://bugzilla.redhat.com/550885 > I don't think external libresample is supported by our > configure script - certainly I've never tested it ... That's likely. I wanted to give it a _very_ quick test and configure bailed out saying that a system library was not available. I only skimmed over config.log and then examined Fedora's libresample-devel package where I discovered breakage. > > When using libsamplerate, the recording stops early because Audacity's > > resampling code sets an "end of input" flag for all sample input > > buffers. If not doing that, the problem disappears here. > > Sounds like there may be a genuine bug here, which would of course > remain regardless of using internal / external libsamplerate. I think we > need to split this into two different bugs at this point. The work-around I use is attached. Hopefully the bug reporter will give the refreshed build a try and confirm that it fixes the issue for him too ( http://bugzilla.redhat.com/550730 ). |
From: Michael S. <msc...@gm...> - 2009-12-30 22:47:52
Attachments:
audacity-1.3.10-resample.patch
|
> The work-around I use is attached. Hopefully the bug reporter will give > the refreshed build a try and confirm that it fixes the issue for him too > ( http://bugzilla.redhat.com/550730 ). The attachment is not missing this time. ;) |
From: Richard A. <ri...@au...> - 2010-01-03 20:15:41
Attachments:
better-resample.patch
|
On Wed, 2009-12-30 at 23:47 +0100, Michael Schwendt wrote: > > The work-around I use is attached. Hopefully the bug reporter will give > > the refreshed build a try and confirm that it fixes the issue for him too > > ( http://bugzilla.redhat.com/550730 ). > > The attachment is not missing this time. ;) Good, but there is a potential issue when the stream is stopped. If we don't set that flag, then some samples that were captured may never get processed and so never get recorded to disk. I've changed it so that this flag is set when the portaudio stream is not running (i.e. during cleanup) which resolves this issue. I've tested and proved that this patch fixes the immediate issue (recording stopping dead after the first batch of audio is resampled), I can't think of a test case for the flushing issue so I haven't tested it, but it all seems to be in order. Is this good to go into CVS before 1.3.11 release someone? Richard |
From: Richard A. <ri...@au...> - 2010-01-08 22:35:16
|
On Sun, 2010-01-03 at 20:15 +0000, Richard Ash wrote: > Good, but there is a potential issue when the stream is stopped. If we > don't set that flag, then some samples that were captured may never get > processed and so never get recorded to disk. I've changed it so that > this flag is set when the portaudio stream is not running (i.e. during > cleanup) which resolves this issue. > > I've tested and proved that this patch fixes the immediate issue > (recording stopping dead after the first batch of audio is resampled), I > can't think of a test case for the flushing issue so I haven't tested > it, but it all seems to be in order. > > Is this good to go into CVS before 1.3.11 release someone? I've now committed this, as no-one had responded on it and we now don't look like doing a release quickly. Richard |