Audacity tries playback to wrong device while recording

[tingo]

This suggests me that the problem might be in the way freebsd accesses the sound card. Apparently when it is recording it blocks any playback.

Nice try - but no cigar (Seriously? What do you think FreeBSD is? A toy operating system?)

Do you have some other app that uses the sound card? For example a media player. Try this tests:

1) Open an mp3 or wav in another app and start playing it. You get sound right? Then start recording in audacity while it is playing on the other app. Does it keeps playing on the other app? Does it record properly in audacity?

2) Try the opposite sequence: first put audacity recording. Then while it is recording start playback in the other app. Does it play?

3) Try playback only, but on audacity and the other app simultaneously. Like before try both sequences.

Meanwhile I'll try to get the attention of some of the developers to this issue.

I tested all three scenarios, using Audacity and mplayer (it was just the nearest music player).
In all three scenarios, playback worked fine, from both applications (where appropriate). Recording also worked fine, in both scenario 1 and 2.

[tingo]

Does this USB gizmo support OS'es other than Windows?

Linux and Mac OS X.

Does the software that comes with the gizmo allow software playthrough?

Yes, it does. Drum roll - the software delivered with this gizmo is ... Audacity!

It's possible you may have come across a variant of this bug:
http://bugzilla.audacityteam.org/show_bug.cgi?id=29

I've read the whole log for that bug. FWIW, I don't think that bug applies. I have none of the symptoms described in there relating to missing or greyed out controls.

If you believe your inbuilt device is full duplex, has correct drivers meant for FreeBSD etc. then try disconnecting the USB gizmo and record from a mic or something else connected to the sound device. Does Audacity software playthrough or overdub work now?

Yes, input device is full duplex, and has correct drivers (again, do people think that FreeBSD is a toy operating system?)
I connected a microphone to the mic in on the built in soundcard, and tried recording.
- software playthrough works
but: it is worth noting that I have sound in my speakers both when software playthrough is on, and when it is off.
- overdub works

But all you have proven with this test it that the problem I reported doesn't show up if audacity is using the same device for both recording and playback.

Does the computer have a line-in? That is usually the best way to record cassettes unless you have a significant noise problem with the inbuilt sound device.

It does, and I am planning on unpacking my old cassette deck later, and compare that to the usb gizmo, to figure out if there is a difference in sound quality (the tapes are so old, that the point might be moot).

[bgravato]

This suggests me that the problem might be in the way freebsd accesses the sound card. Apparently when it is recording it blocks any playback.

Nice try - but no cigar (Seriously? What do you think FreeBSD is? A toy operating system?)

No, I don't. Maybe I wasn't very explicit in my comment... I should have said "in the way freebsd drivers (for your sound card) access the card".

When I first bought my Asus Xonar Essence STX sound card its support on linux was very very limited... I had to wait for a couple of more recent alsa releases to get it to work properly in linux. For example, the headphones output on the card can be configured for different headpones' impedances, I only got access to change this option in linux very recently.
I was suggesting that the freebsd drivers for your sound card might be suffering the same problem... as we know most manufacturers don't care to provide drivers for non-windows systems...

Anyway, from your tests it looks like it's not a problem of the audio drivers and that's what I was trying to decipher...

Beyond this point I'm sure what else to tell you...

Off-topic: I've tried (shortly) FreeBSD (as well as OpenBSD) many years ago (maybe 12 years or more) and I was impressed by FreeBSD stability and in particular by its TCP/IP stack then. I do take *BSD's seriously!

[Gale Andrews]

My point too is not that FreeBSD is a "toy" OS, but that it is a fringe OS that hardware manufacturers may not have taken into account when writing drivers.

I've read the whole log for http://bugzilla.audacityteam.org/show_bug.cgi?id=29. FWIW, I don't think that bug applies. I have none of the symptoms described in there relating to missing or greyed out controls.

If you believe your inbuilt device is full duplex, has correct drivers meant for FreeBSD etc. then try disconnecting the USB gizmo and record from a mic or something else connected to the sound device. Does Audacity software playthrough or overdub work now?

Yes, input device is full duplex, and has correct drivers (again, do people think that FreeBSD is a toy operating system?)
I connected a microphone to the mic in on the built in soundcard, and tried recording.
- software playthrough works
but: it is worth noting that I have sound in my speakers both when software playthrough is on, and when it is off.
- overdub works

It seems then that you have the mic unmuted on the playback side of the sound card. To test Audacity's software playthrough you would have to turn the feature off so that you could not hear the mic input with software playthrough off.

But all you have proven with this test it that the problem I reported doesn't show up if audacity is using the same device for both recording and playback.

When the mic input can't be heard with software playthrough off, it could still show there is a variant of bug 29 in play as per my suggestion (adding the external device breaks proper interaction with the inbuilt device).

Do you have some other way to set the playback device to the inbuilt device, other than choosing "/dev/dsp" in Audacity preferences? Like choosing "alsa:default" and setting the default in alsamixer?



Gale

[tingo]

My point too is not that FreeBSD is a "toy" OS, but that it is a fringe OS that hardware manufacturers may not have taken into account when writing drivers.

I see. Well, very few hardware manufacturers actually make drivers for FreeBSD (there are exceptions of course); most of the drivers are made by BSD developers.

It seems then that you have the mic unmuted on the playback side of the sound card. To test Audacity's software playthrough you would have to turn the feature off so that you could not hear the mic input with software playthrough off.

Hmm, I don't know how to do that. There are no apparent controls in mixer or it graphical equivalent for that.

Do you have some other way to set the playback device to the inbuilt device, other than choosing "/dev/dsp" in Audacity preferences? Like choosing "alsa:default" and setting the default in alsamixer?

FreeBSD uses OSS, not alsa. In Audacity, preferences, devices, interface, the only choice for "Host:" is "OSS". Below that is a line which reads "Using: PortAudio V19-devel (built May 5 2011 02:55:28)"
So I don't think I can choose the playback device any other way.

[Gale Andrews]

FreeBSD uses OSS, not alsa.

Well that's another "fringe" element then. OSS isn't exactly unsupported in 1.3 but it's quite rare now. I wasn't aware that generally, Audacity software playthrough did not work with external devices under OSS, but if you want me to put you in touch with a user who is very keen on OSS he might be able to answer that one. If so, please send me a Private Message.

Meantime I would guess you could install JACK to try and force the USB input to play through the inbuilt device.





Gale

[tingo]

Well that's another "fringe" element then. OSS isn't exactly unsupported in 1.3 but it's quite rare now.

And I thought you (the Audacity team) was using PortAudio to get "Portable Cross-platform Audio I/O".

I wasn't aware that generally, Audacity software playthrough did not work with external devices under OSS, but if you want me to put you in touch with a user who is very keen on OSS he might be able to answer that one. If so, please send me a Private Message.

Well, this is just a bug report. I was kinda hoping that developers would be interested in those, in order to fix bugs and making sure that Audacity works the best it can on all supported platforms.
However, I'll take all the help I can get. PM in a few secs.

Meantime I would guess you could install JACK to try and force the USB input to play through the inbuilt device.

I've tried JACK on FreeBSD before, I haven't had much success (it might be because I do not know enough how to set it all up to get it working).

[Gale Andrews]

@Tingo, I'll pass on your address to the OSS user. There will be more interest in a "bug report" if other OSS users can confirm your finding that software playthrough does not work for USB devices. Very few people use OSS now, so there are almost no reports about it.


Gale

[bgravato]

@Tingo, I'll pass on your address to the OSS user. There will be more interest in a "bug report" if other OSS users can confirm your finding that software playthrough does not work for USB devices. Very few people use OSS now, so there are almost no reports about it.

I can try to test that on Linux if I manage to put oss working with my usb device. Please remind me of this next week.

[tingo]

Another data point:

This suggests me that the problem might be in the way freebsd accesses the sound card. Apparently when it is recording it blocks any playback.

I just tried this:

Code: Select all

[email protected]$ cat /dev/dsp1.0 > /dev/dsp0.0
^C
[email protected]$

and got the (recorded) sound in my speakers.
And I can playback the file by doing

Code: Select all

[email protected]$ cat soundfile.test > /dev/dsp0.0

I guess that proves that FreeBSD doesn't do any blocking while recording.