[alsa-devel] capture line-out
Is it possible to capture/record line-out (or simply 'what the user hears')? I'm writing 'fraps for linux' and so far I have video capturing implemented and that works great, but users are also requesting sound-capturing and I'm looking into how that could be done.
thanks tom
On 03/26/2007 10:26 AM, Tomas Carnecky wrote:
Is it possible to capture/record line-out (or simply 'what the user hears')?
Many (most?) soundcards have a "mix" capture source that captures "that which leaves the mixer" which is close to what you want. It's not quite the same since it for example might not take into account something like a master mute which is likely positioned _after_ the mixer. I believe it's the best that's generally available though (but note that not all cards have one either).
Rene.
Rene Herman wrote:
On 03/26/2007 10:26 AM, Tomas Carnecky wrote:
Is it possible to capture/record line-out (or simply 'what the user hears')?
Many (most?) soundcards have a "mix" capture source that captures "that which leaves the mixer" which is close to what you want. It's not quite the same since it for example might not take into account something like a master mute which is likely positioned _after_ the mixer. I believe it's the best that's generally available though (but note that not all cards have one either).
Thanks. Works great on my ICE1724. But there's one small problem: I need to capture both 'Mic' and 'Mix' - but independently from different applications. I want TeamSpeak capture 'Mic' and my app capture 'Mix'. is that possible?
tom
On 03/26/2007 04:40 PM, Tomas Carnecky wrote:
Thanks. Works great on my ICE1724. But there's one small problem: I need to capture both 'Mic' and 'Mix' - but independently from different applications. I want TeamSpeak capture 'Mic' and my app capture 'Mix'. is that possible?
No, as far as I'm aware that's not possible,at least not generally. Allow for someone correcting me, as I've little experience with capture and there will be some cards out there that allow this but generally the capture source is a card-global setting.
It's not something that can be done just through software; the card needs to provide multiple independent capture sources...
Rene.
Rene Herman wrote:
On 03/26/2007 04:40 PM, Tomas Carnecky wrote:
Thanks. Works great on my ICE1724. But there's one small problem: I need to capture both 'Mic' and 'Mix' - but independently from different applications. I want TeamSpeak capture 'Mic' and my app capture 'Mix'. is that possible?
It's not something that can be done just through software; the card needs to provide multiple independent capture sources...
Hm.. but if the card has multiple capture sources, does the ALSA API allow to select which source to capture?
It's really a bummer that it's not possible on simple soundcards, and I'm wondering how Fraps[1] works together with TeamSpeak (under Windows though, but I'd imagine they'd have the same problem).
tom
On 03/26/2007 06:15 PM, Tomas Carnecky wrote:
Hm.. but if the card has multiple capture sources, does the ALSA API allow to select which source to capture?
A driver writer would, I imagine, export the functionalty as a seperate capture device; /dev/snd/pcmC0D1c, /proc/asound/card0/pcm1c, hw:0,1, ..
So, yes, one app would capture from hw:0,0 and the other from hw:0,1
It's really a bummer that it's not possible on simple soundcards, and I'm wondering how Fraps[1] works together with TeamSpeak (under Windows though, but I'd imagine they'd have the same problem).
Err, yes. I don't know, but does Teamspeak use the Windows API? If so, maybe Fraps captures at the DirectX level and then shoves it back into the API so that Windows doesn't even notice. Only guessing...
Rene.
On 03/26/2007 06:07 PM, Rene Herman wrote:
Err, yes. I don't know, but does Teamspeak use the Windows API? If so, maybe Fraps captures at the DirectX level and then shoves it back into the API so that Windows doesn't even notice. Only guessing...
Forget about this -- was solving a different problem... dunno.
Rene.
Rene Herman wrote:
On 03/26/2007 06:15 PM, Tomas Carnecky wrote:
Hm.. but if the card has multiple capture sources, does the ALSA API allow to select which source to capture?
A driver writer would, I imagine, export the functionalty as a seperate capture device; /dev/snd/pcmC0D1c, /proc/asound/card0/pcm1c, hw:0,1, ..
So, yes, one app would capture from hw:0,0 and the other from hw:0,1
It's really a bummer that it's not possible on simple soundcards, and I'm wondering how Fraps[1] works together with TeamSpeak (under Windows though, but I'd imagine they'd have the same problem).
Err, yes. I don't know, but does Teamspeak use the Windows API? If so, maybe Fraps captures at the DirectX level and then shoves it back into the API so that Windows doesn't even notice. Only guessing...
Rene.
Rene Herman wrote:
Err, yes. I don't know, but does Teamspeak use the Windows API? If so, maybe Fraps captures at the DirectX level and then shoves it back into the API so that Windows doesn't even notice. Only guessing...
Sorry about the previous mail.. beryl more often than not sucks :(
Well.. back to the problem. If I understood you correctly, you suggest to 'hook' functions and intercept the sound data before it's sent to the hardware, correct? That is more or less what I do when capturing the graphics (I hook glXSwapBuffers() which the app calls after it finishes drawing every single frame). That works quite well, but for sound, I'd have to hook more than one function (mmap vs. write) and implement my own software mixer in case the app uses more than one device. That would make it much more complicated.
A better solution would be to temporarily switch the capture device to 'Mic' before the user enables capturing in TeamSpeak (usually using a hotkey) and starts speaking and set it back to 'Mix' after he finishes.
tom
On 03/27/2007 03:18 AM, Tomas Carnecky wrote:
If I understood you correctly, you suggest to 'hook' functions and intercept the sound data before it's sent to the hardware, correct?
I must say I wasn't suggesting much of anything really. Was just wondering, a little, what Windows was doing...
The output mixer (that which the "Mix" capture source grabs the output of) is about mixing analog inputs (mic, line in, aux in, ...) in with the output from the chip's DAC and those analog inputs aren't "sent to the hardware" so hooking the API wouldn't be of help with those.
If you'd be satisfied with only the "PCM source" then yes, you could hook the API for that and let the mixer just capture the mic. Would get you better quality. The Mix capture source for PCM will go:
Software -> Chip -> DAC -> Output Mixer -> Input Mixer -> ADC -> Chip -> Software
which sort of has one scratch one's head when no mixing in of analog sources is desired.
In the absence of hardware support for multiple capture sources, I don't have any bright ideas about grabbing both "that which the user hears" and the microphine idependently...
But:
A better solution would be to temporarily switch the capture device to 'Mic' before the user enables capturing in TeamSpeak (usually using a hotkey) and starts speaking and set it back to 'Mix' after he finishes.
If that works for you, great :)
Rene.
Rene Herman wrote:
In the absence of hardware support for multiple capture sources, I don't have any bright ideas about grabbing both "that which the user hears" and the microphine idependently...
I wrote a support ticket to the Fraps team. They also have no solution for the problem. But thanks for the help and the explanation how the sound hardware works :) I will figure something out and get back if I have further questions :)
tom
participants (2)
-
Rene Herman -
Tomas Carnecky