* [ALSA - lib 0001819]: Monitor capability feature request
@ 2006-02-04 18:42 bugtrack
0 siblings, 0 replies; 6+ messages in thread
From: bugtrack @ 2006-02-04 18:42 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1819>
======================================================================
Reported By: djandruczyk
Assigned To:
======================================================================
Project: ALSA - lib
Issue ID: 1819
Category: 0_general
Reproducibility: N/A
Severity: feature
Priority: normal
Status: new
======================================================================
Date Submitted: 02-04-2006 19:42 CET
Last Modified: 02-04-2006 19:42 CET
======================================================================
Summary: Monitor capability feature request
Description:
I'd like to suggest a potential feature with the capability of monitoring
ANY pcm output (or combination of simultaneous outputs). The aim being to
be able to do the following via alsa-lib:
1. record output from arbritrary applications or combination thereof
without requiring any application modification and without looping back
the physical outputs to inputs on the sound hardware (which introduces
noise and unwanted latency and use of a recording source that might
otherwise be in use.
2. perform monitoring of select streams (in the case of multiple pcm
streams running at once)
>From the application's point of view that would want to use this I
envision something along these lines:
- App registers a callback with ALSA-lib to be notified if a new stream is
created or destroyed.
- App then queries alsa lib for a current list of running streams (whether
to physical devices or streams feeding into dmix)
- App requests a "monitor connection" to a stream or combination of
streams and registers a callback function to be called anytime this stream
is upated from an application (limitation in that all streams requested
share same SW params for simplicity) This should be flexible in the case
of dmix to be able to monitor 1 feed up to n feeds where n being the max
number of streams that dmix is handling concurrently. The monitored
connection will have a total number of channels equal to the sum of
monitored channels selected.
for example: lets say dmix is multiplexing 3 applications to one physical
hw:0 device. the monitor requests 2 out of those three (for wahtever
reason, it doesn't matter) The monitor callback should deliver the data to
the callback as a 4 channel stream in the format of:
L (stream 1),R(stream 1), L(Stream 2), R(stram2) (interleaved). The
restriction being that the SW params of the streams that are to be
monitored must all match, otherwise it would become very difficult to
calculate and handle all the possible permutations of handling mixmatched
streams.
- App's callback function is called each time the outside application
issues a write to ALSA lib and is able to monitor the audio stream from
said app in realtime. If outside application closes, the notification
callback will be called and the app monitoring the stream will gracefully
handle the event, deregister the monitor callbacks, and if wanted,
re-query also lib for current streams and connect to another.
Potential issues:
This would ONLY work for applications using the ALSA lib library and PCM
plugins plughw, dmix, etc. It would (probably) NOT function for direct
access, to hw:0 (thought it may be implementable, I don't know enough of
ALSA internals to know if it would be possible). It most definitely would
not work for things that mmap the sound device buffer directly, but I
would guess that a large portion of applications do not use that method.
(though I may be wrong and would appreciate a correction if I am so)
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
02-04-06 19:42 djandruczyk New Issue
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ALSA - lib 0001819]: Monitor capability feature request
@ 2006-02-04 18:53 bugtrack
0 siblings, 0 replies; 6+ messages in thread
From: bugtrack @ 2006-02-04 18:53 UTC (permalink / raw)
To: alsa-devel
The following issue has been RESOLVED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1819>
======================================================================
Reported By: djandruczyk
Assigned To: rlrevell
======================================================================
Project: ALSA - lib
Issue ID: 1819
Category: 0_general
Reproducibility: N/A
Severity: feature
Priority: normal
Status: resolved
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 02-04-2006 19:42 CET
Last Modified: 02-04-2006 19:53 CET
======================================================================
Summary: Monitor capability feature request
Description:
I'd like to suggest a potential feature with the capability of monitoring
ANY pcm output (or combination of simultaneous outputs). The aim being to
be able to do the following via alsa-lib:
1. record output from arbritrary applications or combination thereof
without requiring any application modification and without looping back
the physical outputs to inputs on the sound hardware (which introduces
noise and unwanted latency and use of a recording source that might
otherwise be in use.
2. perform monitoring of select streams (in the case of multiple pcm
streams running at once)
>From the application's point of view that would want to use this I
envision something along these lines:
- App registers a callback with ALSA-lib to be notified if a new stream is
created or destroyed.
- App then queries alsa lib for a current list of running streams (whether
to physical devices or streams feeding into dmix)
- App requests a "monitor connection" to a stream or combination of
streams and registers a callback function to be called anytime this stream
is upated from an application (limitation in that all streams requested
share same SW params for simplicity) This should be flexible in the case
of dmix to be able to monitor 1 feed up to n feeds where n being the max
number of streams that dmix is handling concurrently. The monitored
connection will have a total number of channels equal to the sum of
monitored channels selected.
for example: lets say dmix is multiplexing 3 applications to one physical
hw:0 device. the monitor requests 2 out of those three (for wahtever
reason, it doesn't matter) The monitor callback should deliver the data to
the callback as a 4 channel stream in the format of:
L (stream 1),R(stream 1), L(Stream 2), R(stram2) (interleaved). The
restriction being that the SW params of the streams that are to be
monitored must all match, otherwise it would become very difficult to
calculate and handle all the possible permutations of handling mixmatched
streams.
- App's callback function is called each time the outside application
issues a write to ALSA lib and is able to monitor the audio stream from
said app in realtime. If outside application closes, the notification
callback will be called and the app monitoring the stream will gracefully
handle the event, deregister the monitor callbacks, and if wanted,
re-query also lib for current streams and connect to another.
Potential issues:
This would ONLY work for applications using the ALSA lib library and PCM
plugins plughw, dmix, etc. It would (probably) NOT function for direct
access, to hw:0 (thought it may be implementable, I don't know enough of
ALSA internals to know if it would be possible). It most definitely would
not work for things that mmap the sound device buffer directly, but I
would guess that a large portion of applications do not use that method.
(though I may be wrong and would appreciate a correction if I am so)
======================================================================
----------------------------------------------------------------------
rlrevell - 02-04-06 19:53
----------------------------------------------------------------------
The functionality you want already exists, see JACK.
Issue History
Date Modified Username Field Change
======================================================================
02-04-06 19:42 djandruczyk New Issue
02-04-06 19:53 rlrevell Status new => resolved
02-04-06 19:53 rlrevell Resolution open => fixed
02-04-06 19:53 rlrevell Assigned To => rlrevell
02-04-06 19:53 rlrevell Note Added: 0007921
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ALSA - lib 0001819]: Monitor capability feature request
@ 2006-02-04 19:22 bugtrack
0 siblings, 0 replies; 6+ messages in thread
From: bugtrack @ 2006-02-04 19:22 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1819>
======================================================================
Reported By: djandruczyk
Assigned To: rlrevell
======================================================================
Project: ALSA - lib
Issue ID: 1819
Category: 0_general
Reproducibility: N/A
Severity: feature
Priority: normal
Status: resolved
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 02-04-2006 19:42 CET
Last Modified: 02-04-2006 20:22 CET
======================================================================
Summary: Monitor capability feature request
Description:
I'd like to suggest a potential feature with the capability of monitoring
ANY pcm output (or combination of simultaneous outputs). The aim being to
be able to do the following via alsa-lib:
1. record output from arbritrary applications or combination thereof
without requiring any application modification and without looping back
the physical outputs to inputs on the sound hardware (which introduces
noise and unwanted latency and use of a recording source that might
otherwise be in use.
2. perform monitoring of select streams (in the case of multiple pcm
streams running at once)
>From the application's point of view that would want to use this I
envision something along these lines:
- App registers a callback with ALSA-lib to be notified if a new stream is
created or destroyed.
- App then queries alsa lib for a current list of running streams (whether
to physical devices or streams feeding into dmix)
- App requests a "monitor connection" to a stream or combination of
streams and registers a callback function to be called anytime this stream
is upated from an application (limitation in that all streams requested
share same SW params for simplicity) This should be flexible in the case
of dmix to be able to monitor 1 feed up to n feeds where n being the max
number of streams that dmix is handling concurrently. The monitored
connection will have a total number of channels equal to the sum of
monitored channels selected.
for example: lets say dmix is multiplexing 3 applications to one physical
hw:0 device. the monitor requests 2 out of those three (for wahtever
reason, it doesn't matter) The monitor callback should deliver the data to
the callback as a 4 channel stream in the format of:
L (stream 1),R(stream 1), L(Stream 2), R(stram2) (interleaved). The
restriction being that the SW params of the streams that are to be
monitored must all match, otherwise it would become very difficult to
calculate and handle all the possible permutations of handling mixmatched
streams.
- App's callback function is called each time the outside application
issues a write to ALSA lib and is able to monitor the audio stream from
said app in realtime. If outside application closes, the notification
callback will be called and the app monitoring the stream will gracefully
handle the event, deregister the monitor callbacks, and if wanted,
re-query also lib for current streams and connect to another.
Potential issues:
This would ONLY work for applications using the ALSA lib library and PCM
plugins plughw, dmix, etc. It would (probably) NOT function for direct
access, to hw:0 (thought it may be implementable, I don't know enough of
ALSA internals to know if it would be possible). It most definitely would
not work for things that mmap the sound device buffer directly, but I
would guess that a large portion of applications do not use that method.
(though I may be wrong and would appreciate a correction if I am so)
======================================================================
----------------------------------------------------------------------
rlrevell - 02-04-06 19:53
----------------------------------------------------------------------
The functionality you want already exists, see JACK.
----------------------------------------------------------------------
perex - 02-04-06 20:22
----------------------------------------------------------------------
JACK is not exactly what user requests, but the file plugin can be inserted
into the alsa-lib pcm plugin chain, so that the stream can be grabbed. Of
course, it's only very simple method without sample organization
description, rate and other stream parameters, but a more complex file
plugin can be created.
Issue History
Date Modified Username Field Change
======================================================================
02-04-06 19:42 djandruczyk New Issue
02-04-06 19:53 rlrevell Status new => resolved
02-04-06 19:53 rlrevell Resolution open => fixed
02-04-06 19:53 rlrevell Assigned To => rlrevell
02-04-06 19:53 rlrevell Note Added: 0007921
02-04-06 20:22 perex Note Added: 0007923
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ALSA - lib 0001819]: Monitor capability feature request
@ 2006-02-04 19:58 bugtrack
0 siblings, 0 replies; 6+ messages in thread
From: bugtrack @ 2006-02-04 19:58 UTC (permalink / raw)
To: alsa-devel
The following issue has been REOPENED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1819>
======================================================================
Reported By: djandruczyk
Assigned To: rlrevell
======================================================================
Project: ALSA - lib
Issue ID: 1819
Category: 0_general
Reproducibility: N/A
Severity: feature
Priority: normal
Status: feedback
======================================================================
Date Submitted: 02-04-2006 19:42 CET
Last Modified: 02-04-2006 20:58 CET
======================================================================
Summary: Monitor capability feature request
Description:
I'd like to suggest a potential feature with the capability of monitoring
ANY pcm output (or combination of simultaneous outputs). The aim being to
be able to do the following via alsa-lib:
1. record output from arbritrary applications or combination thereof
without requiring any application modification and without looping back
the physical outputs to inputs on the sound hardware (which introduces
noise and unwanted latency and use of a recording source that might
otherwise be in use.
2. perform monitoring of select streams (in the case of multiple pcm
streams running at once)
>From the application's point of view that would want to use this I
envision something along these lines:
- App registers a callback with ALSA-lib to be notified if a new stream is
created or destroyed.
- App then queries alsa lib for a current list of running streams (whether
to physical devices or streams feeding into dmix)
- App requests a "monitor connection" to a stream or combination of
streams and registers a callback function to be called anytime this stream
is upated from an application (limitation in that all streams requested
share same SW params for simplicity) This should be flexible in the case
of dmix to be able to monitor 1 feed up to n feeds where n being the max
number of streams that dmix is handling concurrently. The monitored
connection will have a total number of channels equal to the sum of
monitored channels selected.
for example: lets say dmix is multiplexing 3 applications to one physical
hw:0 device. the monitor requests 2 out of those three (for wahtever
reason, it doesn't matter) The monitor callback should deliver the data to
the callback as a 4 channel stream in the format of:
L (stream 1),R(stream 1), L(Stream 2), R(stram2) (interleaved). The
restriction being that the SW params of the streams that are to be
monitored must all match, otherwise it would become very difficult to
calculate and handle all the possible permutations of handling mixmatched
streams.
- App's callback function is called each time the outside application
issues a write to ALSA lib and is able to monitor the audio stream from
said app in realtime. If outside application closes, the notification
callback will be called and the app monitoring the stream will gracefully
handle the event, deregister the monitor callbacks, and if wanted,
re-query also lib for current streams and connect to another.
Potential issues:
This would ONLY work for applications using the ALSA lib library and PCM
plugins plughw, dmix, etc. It would (probably) NOT function for direct
access, to hw:0 (thought it may be implementable, I don't know enough of
ALSA internals to know if it would be possible). It most definitely would
not work for things that mmap the sound device buffer directly, but I
would guess that a large portion of applications do not use that method.
(though I may be wrong and would appreciate a correction if I am so)
======================================================================
----------------------------------------------------------------------
perex - 02-04-06 20:22
----------------------------------------------------------------------
JACK is not exactly what user requests, but the file plugin can be inserted
into the alsa-lib pcm plugin chain, so that the stream can be grabbed. Of
course, it's only very simple method without sample organization
description, rate and other stream parameters, but a more complex file
plugin can be created.
----------------------------------------------------------------------
djandruczyk - 02-04-06 20:58
----------------------------------------------------------------------
jack isn't necessarily a solution as there are many apps that DO NOT WORK
with jack, and in some cases the application may not have source
availablity for modification.
I've looked into the file plugin but it hasn't worked well, and was next
to impossible to use in an interactive form. (realtime) My primary
motivation for this ability is to be able to monitor/analyze audio streams
in realtime without having to modify any of the apps that may be monitored
(as in some cases they can't). (jack==not all apps work, esd==ick!,
arts==uggh!)
Issue History
Date Modified Username Field Change
======================================================================
02-04-06 19:42 djandruczyk New Issue
02-04-06 19:53 rlrevell Status new => resolved
02-04-06 19:53 rlrevell Resolution open => fixed
02-04-06 19:53 rlrevell Assigned To => rlrevell
02-04-06 19:53 rlrevell Note Added: 0007921
02-04-06 20:22 perex Note Added: 0007923
02-04-06 20:58 djandruczyk Status resolved => feedback
02-04-06 20:58 djandruczyk Resolution fixed => reopened
02-04-06 20:58 djandruczyk Note Added: 0007926
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ALSA - lib 0001819]: Monitor capability feature request
@ 2006-02-05 3:39 bugtrack
0 siblings, 0 replies; 6+ messages in thread
From: bugtrack @ 2006-02-05 3:39 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1819>
======================================================================
Reported By: djandruczyk
Assigned To: rlrevell
======================================================================
Project: ALSA - lib
Issue ID: 1819
Category: 0_general
Reproducibility: N/A
Severity: feature
Priority: normal
Status: feedback
======================================================================
Date Submitted: 02-04-2006 19:42 CET
Last Modified: 02-05-2006 04:39 CET
======================================================================
Summary: Monitor capability feature request
Description:
I'd like to suggest a potential feature with the capability of monitoring
ANY pcm output (or combination of simultaneous outputs). The aim being to
be able to do the following via alsa-lib:
1. record output from arbritrary applications or combination thereof
without requiring any application modification and without looping back
the physical outputs to inputs on the sound hardware (which introduces
noise and unwanted latency and use of a recording source that might
otherwise be in use.
2. perform monitoring of select streams (in the case of multiple pcm
streams running at once)
>From the application's point of view that would want to use this I
envision something along these lines:
- App registers a callback with ALSA-lib to be notified if a new stream is
created or destroyed.
- App then queries alsa lib for a current list of running streams (whether
to physical devices or streams feeding into dmix)
- App requests a "monitor connection" to a stream or combination of
streams and registers a callback function to be called anytime this stream
is upated from an application (limitation in that all streams requested
share same SW params for simplicity) This should be flexible in the case
of dmix to be able to monitor 1 feed up to n feeds where n being the max
number of streams that dmix is handling concurrently. The monitored
connection will have a total number of channels equal to the sum of
monitored channels selected.
for example: lets say dmix is multiplexing 3 applications to one physical
hw:0 device. the monitor requests 2 out of those three (for wahtever
reason, it doesn't matter) The monitor callback should deliver the data to
the callback as a 4 channel stream in the format of:
L (stream 1),R(stream 1), L(Stream 2), R(stram2) (interleaved). The
restriction being that the SW params of the streams that are to be
monitored must all match, otherwise it would become very difficult to
calculate and handle all the possible permutations of handling mixmatched
streams.
- App's callback function is called each time the outside application
issues a write to ALSA lib and is able to monitor the audio stream from
said app in realtime. If outside application closes, the notification
callback will be called and the app monitoring the stream will gracefully
handle the event, deregister the monitor callbacks, and if wanted,
re-query also lib for current streams and connect to another.
Potential issues:
This would ONLY work for applications using the ALSA lib library and PCM
plugins plughw, dmix, etc. It would (probably) NOT function for direct
access, to hw:0 (thought it may be implementable, I don't know enough of
ALSA internals to know if it would be possible). It most definitely would
not work for things that mmap the sound device buffer directly, but I
would guess that a large portion of applications do not use that method.
(though I may be wrong and would appreciate a correction if I am so)
======================================================================
----------------------------------------------------------------------
djandruczyk - 02-04-06 20:58
----------------------------------------------------------------------
jack isn't necessarily a solution as there are many apps that DO NOT WORK
with jack, and in some cases the application may not have source
availablity for modification.
I've looked into the file plugin but it hasn't worked well, and was next
to impossible to use in an interactive form. (realtime) My primary
motivation for this ability is to be able to monitor/analyze audio streams
in realtime without having to modify any of the apps that may be monitored
(as in some cases they can't). (jack==not all apps work, esd==ick!,
arts==uggh!)
----------------------------------------------------------------------
Raymond - 02-05-06 04:39
----------------------------------------------------------------------
Can those sound cards which support hardware mixing use the hardware mixer
to record all the playback ?
Is it feasible to create a virtual pcm catpure device for those sound card
to capture the playback ?
The 8/16 bits audio is already resampled to 48000 Hz by the hardware
sample rate convertor before sending to AC97 codec.
Issue History
Date Modified Username Field Change
======================================================================
02-04-06 19:42 djandruczyk New Issue
02-04-06 19:53 rlrevell Status new => resolved
02-04-06 19:53 rlrevell Resolution open => fixed
02-04-06 19:53 rlrevell Assigned To => rlrevell
02-04-06 19:53 rlrevell Note Added: 0007921
02-04-06 20:22 perex Note Added: 0007923
02-04-06 20:58 djandruczyk Status resolved => feedback
02-04-06 20:58 djandruczyk Resolution fixed => reopened
02-04-06 20:58 djandruczyk Note Added: 0007926
02-05-06 04:39 Raymond Note Added: 0007928
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ALSA - lib 0001819]: Monitor capability feature request
@ 2006-02-07 15:24 bugtrack
0 siblings, 0 replies; 6+ messages in thread
From: bugtrack @ 2006-02-07 15:24 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1819>
======================================================================
Reported By: djandruczyk
Assigned To: rlrevell
======================================================================
Project: ALSA - lib
Issue ID: 1819
Category: 0_general
Reproducibility: N/A
Severity: feature
Priority: normal
Status: feedback
======================================================================
Date Submitted: 02-04-2006 19:42 CET
Last Modified: 02-07-2006 16:24 CET
======================================================================
Summary: Monitor capability feature request
Description:
I'd like to suggest a potential feature with the capability of monitoring
ANY pcm output (or combination of simultaneous outputs). The aim being to
be able to do the following via alsa-lib:
1. record output from arbritrary applications or combination thereof
without requiring any application modification and without looping back
the physical outputs to inputs on the sound hardware (which introduces
noise and unwanted latency and use of a recording source that might
otherwise be in use.
2. perform monitoring of select streams (in the case of multiple pcm
streams running at once)
>From the application's point of view that would want to use this I
envision something along these lines:
- App registers a callback with ALSA-lib to be notified if a new stream is
created or destroyed.
- App then queries alsa lib for a current list of running streams (whether
to physical devices or streams feeding into dmix)
- App requests a "monitor connection" to a stream or combination of
streams and registers a callback function to be called anytime this stream
is upated from an application (limitation in that all streams requested
share same SW params for simplicity) This should be flexible in the case
of dmix to be able to monitor 1 feed up to n feeds where n being the max
number of streams that dmix is handling concurrently. The monitored
connection will have a total number of channels equal to the sum of
monitored channels selected.
for example: lets say dmix is multiplexing 3 applications to one physical
hw:0 device. the monitor requests 2 out of those three (for wahtever
reason, it doesn't matter) The monitor callback should deliver the data to
the callback as a 4 channel stream in the format of:
L (stream 1),R(stream 1), L(Stream 2), R(stram2) (interleaved). The
restriction being that the SW params of the streams that are to be
monitored must all match, otherwise it would become very difficult to
calculate and handle all the possible permutations of handling mixmatched
streams.
- App's callback function is called each time the outside application
issues a write to ALSA lib and is able to monitor the audio stream from
said app in realtime. If outside application closes, the notification
callback will be called and the app monitoring the stream will gracefully
handle the event, deregister the monitor callbacks, and if wanted,
re-query also lib for current streams and connect to another.
Potential issues:
This would ONLY work for applications using the ALSA lib library and PCM
plugins plughw, dmix, etc. It would (probably) NOT function for direct
access, to hw:0 (thought it may be implementable, I don't know enough of
ALSA internals to know if it would be possible). It most definitely would
not work for things that mmap the sound device buffer directly, but I
would guess that a large portion of applications do not use that method.
(though I may be wrong and would appreciate a correction if I am so)
======================================================================
----------------------------------------------------------------------
Raymond - 02-05-06 04:39
----------------------------------------------------------------------
Can those sound cards which support hardware mixing use the hardware mixer
to record all the playback ?
Is it feasible to create a virtual pcm catpure device for those sound card
to capture the playback ?
The 8/16 bits audio is already resampled to 48000 Hz by the hardware
sample rate convertor before sending to AC97 codec.
----------------------------------------------------------------------
perex - 02-07-06 16:24
----------------------------------------------------------------------
Note that the file plugin is the elementary way, how you can do similar
functionality as "tee". Of course, more complex plugin might be created
with additional buffering and "registration" to a daemon which will do the
enumeration of registered streams etc.
If the file plugin cannot be used in realtime, find the culprit. The file
plugin does nothing than a copy of stream samples to a file descriptor.
Even with an arbiter (loopback daemon), the things will be much more
complex.
Issue History
Date Modified Username Field Change
======================================================================
02-04-06 19:42 djandruczyk New Issue
02-04-06 19:53 rlrevell Status new => resolved
02-04-06 19:53 rlrevell Resolution open => fixed
02-04-06 19:53 rlrevell Assigned To => rlrevell
02-04-06 19:53 rlrevell Note Added: 0007921
02-04-06 20:22 perex Note Added: 0007923
02-04-06 20:58 djandruczyk Status resolved => feedback
02-04-06 20:58 djandruczyk Resolution fixed => reopened
02-04-06 20:58 djandruczyk Note Added: 0007926
02-05-06 04:39 Raymond Note Added: 0007928
02-07-06 16:24 perex Note Added: 0007958
======================================================================
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-02-07 15:24 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-07 15:24 [ALSA - lib 0001819]: Monitor capability feature request bugtrack
-- strict thread matches above, loose matches on Subject: below --
2006-02-05 3:39 bugtrack
2006-02-04 19:58 bugtrack
2006-02-04 19:22 bugtrack
2006-02-04 18:53 bugtrack
2006-02-04 18:42 bugtrack
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox