Reliable, Low-Overhead 24-bit Audio Capture on Windows

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Reliable, Low-Overhead 24-bit Audio Capture on Windows

Samuel Adam-2
I am seeking the lowest-overhead way to grab 24-bit audio straight from a  
piece of 24-bit hardware.  The problem is, Sox is recording 16-bit samples  
by default (although it does detect the sample rate correctly).  Adding a  
-3 to the command line forces Sox to record 24-bit; however, the 16-bit  
default leads me to question whether Sox is capturing 16-bit samples, then  
upsizing.  Particularly worrying is -4 makes Sox merrily report a 32-bit  
input.

This is on Windows XP/2K, with the SoX v14.3.1 (2010-04-10) binary  
downloaded from Sourceforge.  My primary problem is that I can’t find the  
magic incantation to have Sox actually tell me what precision it detects  
 from the hardware driver.

Here are the command lines I have tried for capturing 30 seconds’ worth of  
audio:

sox -t waveaudio "My Audio Hardware" captured.wav trim 0 30
Results in a 16-bit recording.

sox -3 -t waveaudio "My Audio Hardware" captured.wav trim 0 30
Results in a 24-bit recording; but I can’t tell if Sox is getting 24 bits  
 from the source, or pointlessly expanding 16-bit samples.

sox -4 -t waveaudio "My Audio Hardware" captured.wav trim 0 30
Results in a 32-bit recording, with no other visible difference from using  
-3.

sox -V4 -? -t waveaudio "My Audio Hardware" -n stats trim 0 1
…where ? represents 3 or 4.  Verbose stderr reports input as however many  
bits I specified; however, stats always speak of 16 bits (no matter what!).

By the way, the hardware in question has an ASIO driver; I am guessing  
that Sox’s waveaudio device does not use that, but uses the Windows  
waveaudio functions instead.  A further educated guess (knowing Winapi) is  
that there are hoops to jump through to get 24-bit audio, and Sox might  
not be doing that.  I might take a look at the sources in my copious free  
time; but perhaps somebody who already knows the Sox code could answer  
this off-hand.

Tips on Sox’s behavior would be appreciated—as would any leads on the  
simplest reliable tools for dumping a 24-bit audio stream from mic to  
file.  Essentially, I seek the conceptual equivalent of `cat /dev/whatever  
> /path/to/output.pcm`.  I think a simple snip of ASIO C code would work  
best; but I haven’t yet had a chance to try it.

Very truly,

Samuel Adam <http://certifound.com/>
763 Montgomery Road
Hillsborough, NJ  08844-1304 • United States
ANNOUNCING: Adam v. Supreme Court of New Jersey, et al.
Complaint: http://certifound.com/+77AD29C
Media Letter (cf. Madoff!): http://certifound.com/+29A9AE2

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Reliable, Low-Overhead 24-bit Audio Capture on Windows

Doug Cook-2
Sox is recording at 16 bits and converting the result to your requested sample depth. The current waveaudio support is 16-bit only. The hoops in WinAPI aren't terribly great, but it added some complexity regarding the detection of 24/32 bit support and negotiating the "best" sample rate without introducing incompatibilities with earlier versions of Windows.

On Mon, Jan 17, 2011 at 2:58 PM, Samuel Adam <[hidden email]> wrote:
I am seeking the lowest-overhead way to grab 24-bit audio straight from a
piece of 24-bit hardware.  The problem is, Sox is recording 16-bit samples
by default (although it does detect the sample rate correctly).  Adding a
-3 to the command line forces Sox to record 24-bit; however, the 16-bit
default leads me to question whether Sox is capturing 16-bit samples, then
upsizing.  Particularly worrying is -4 makes Sox merrily report a 32-bit
input.

This is on Windows XP/2K, with the SoX v14.3.1 (2010-04-10) binary
downloaded from Sourceforge.  My primary problem is that I can’t find the
magic incantation to have Sox actually tell me what precision it detects
 from the hardware driver.

Here are the command lines I have tried for capturing 30 seconds’ worth of
audio:

sox -t waveaudio "My Audio Hardware" captured.wav trim 0 30
Results in a 16-bit recording.

sox -3 -t waveaudio "My Audio Hardware" captured.wav trim 0 30
Results in a 24-bit recording; but I can’t tell if Sox is getting 24 bits
 from the source, or pointlessly expanding 16-bit samples.

sox -4 -t waveaudio "My Audio Hardware" captured.wav trim 0 30
Results in a 32-bit recording, with no other visible difference from using
-3.

sox -V4 -? -t waveaudio "My Audio Hardware" -n stats trim 0 1
…where ? represents 3 or 4.  Verbose stderr reports input as however many
bits I specified; however, stats always speak of 16 bits (no matter what!).

By the way, the hardware in question has an ASIO driver; I am guessing
that Sox’s waveaudio device does not use that, but uses the Windows
waveaudio functions instead.  A further educated guess (knowing Winapi) is
that there are hoops to jump through to get 24-bit audio, and Sox might
not be doing that.  I might take a look at the sources in my copious free
time; but perhaps somebody who already knows the Sox code could answer
this off-hand.

Tips on Sox’s behavior would be appreciated—as would any leads on the
simplest reliable tools for dumping a 24-bit audio stream from mic to
file.  Essentially, I seek the conceptual equivalent of `cat /dev/whatever
> /path/to/output.pcm`.  I think a simple snip of ASIO C code would work
best; but I haven’t yet had a chance to try it.

Very truly,

Samuel Adam <http://certifound.com/>
763 Montgomery Road
Hillsborough, NJ  08844-1304 • United States
ANNOUNCING: Adam v. Supreme Court of New Jersey, et al.
Complaint: http://certifound.com/+77AD29C
Media Letter (cf. Madoff!): http://certifound.com/+29A9AE2

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Reliable, Low-Overhead 24-bit Audio Capture on Windows

Rüdiger Hausmann
Just to prevent irritations: sox *does* capture 24bit length native under linux, doesn't it?
Rüdiger

Am 18.01.2011 01:30, schrieb Doug Cook:
Sox is recording at 16 bits and converting the result to your requested sample depth. The current waveaudio support is 16-bit only. The hoops in WinAPI aren't terribly great, but it added some complexity regarding the detection of 24/32 bit support and negotiating the "best" sample rate without introducing incompatibilities with earlier versions of Windows.

On Mon, Jan 17, 2011 at 2:58 PM, Samuel Adam <[hidden email]> wrote:
I am seeking the lowest-overhead way to grab 24-bit audio straight from a
piece of 24-bit hardware.  The problem is, Sox is recording 16-bit samples
by default (although it does detect the sample rate correctly).  Adding a
-3 to the command line forces Sox to record 24-bit; however, the 16-bit
default leads me to question whether Sox is capturing 16-bit samples, then
upsizing.  Particularly worrying is -4 makes Sox merrily report a 32-bit
input.

This is on Windows XP/2K, with the SoX v14.3.1 (2010-04-10) binary
downloaded from Sourceforge.  My primary problem is that I can’t find the
magic incantation to have Sox actually tell me what precision it detects
 from the hardware driver.

Here are the command lines I have tried for capturing 30 seconds’ worth of
audio:

sox -t waveaudio "My Audio Hardware" captured.wav trim 0 30
Results in a 16-bit recording.

sox -3 -t waveaudio "My Audio Hardware" captured.wav trim 0 30
Results in a 24-bit recording; but I can’t tell if Sox is getting 24 bits
 from the source, or pointlessly expanding 16-bit samples.

sox -4 -t waveaudio "My Audio Hardware" captured.wav trim 0 30
Results in a 32-bit recording, with no other visible difference from using
-3.

sox -V4 -? -t waveaudio "My Audio Hardware" -n stats trim 0 1
…where ? represents 3 or 4.  Verbose stderr reports input as however many
bits I specified; however, stats always speak of 16 bits (no matter what!).

By the way, the hardware in question has an ASIO driver; I am guessing
that Sox’s waveaudio device does not use that, but uses the Windows
waveaudio functions instead.  A further educated guess (knowing Winapi) is
that there are hoops to jump through to get 24-bit audio, and Sox might
not be doing that.  I might take a look at the sources in my copious free
time; but perhaps somebody who already knows the Sox code could answer
this off-hand.

Tips on Sox’s behavior would be appreciated—as would any leads on the
simplest reliable tools for dumping a 24-bit audio stream from mic to
file.  Essentially, I seek the conceptual equivalent of `cat /dev/whatever
> /path/to/output.pcm`.  I think a simple snip of ASIO C code would work
best; but I haven’t yet had a chance to try it.

Very truly,

Samuel Adam <http://certifound.com/>
763 Montgomery Road
Hillsborough, NJ  08844-1304 • United States
ANNOUNCING: Adam v. Supreme Court of New Jersey, et al.
Complaint: http://certifound.com/+77AD29C
Media Letter (cf. Madoff!): http://certifound.com/+29A9AE2

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users

------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________ Sox-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/sox-users


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Reliable, Low-Overhead 24-bit Audio Capture on Windows

Samuel Adam-2
In reply to this post by Doug Cook-2
On Mon, 17 Jan 2011 19:30:57 -0500, Doug Cook  
<[hidden email]> wrote:

> Sox is recording at 16 bits and converting the result to your requested
> sample depth. The current waveaudio support is 16-bit only. The hoops in
> WinAPI aren't terribly great, but it added some complexity regarding the
> detection of 24/32 bit support and negotiating the "best" sample rate
> without introducing incompatibilities with earlier versions of Windows.

Thanks for the concise answer.  I see that you are evidently the author of  
waveaudio.c.  Glancing through MSDN, unless I am wildly off-base, I  
believe this sums up the problem:

http://msdn.microsoft.com/en-us/library/dd757714.aspx
  ------ begin quotation
        WAVEFORMATEXTENSIBLE Structure
       
        …higher sample resolutions than allowed by WAVEFORMATEX…
       
        Minimum supported client Windows XP
        Minimum supported server Windows Server 2003
        Header Mmreg.h
  -------- end quotation

For the archives (and for anybody who wants to brave the maze of  
2K/XP/Vista/7 audio API changes), I hope that provides a nudge in the  
right direction.  By the way, kudos for keeping Windows 2000 compatibility.

As for me, it seems I’ll have to find something else.  It looks trivial to  
whip up a dumb audio dumper for my needs using Steinberg’s ASIO API; I  
guess I will need to go that route at some point.

Very truly,

Samuel Adam <http://certifound.com/>
763 Montgomery Road
Hillsborough, NJ  08844-1304 • United States
ANNOUNCING: Adam v. Supreme Court of New Jersey, et al.
Complaint: http://certifound.com/+77AD29C
Media Letter (cf. Madoff!): http://certifound.com/+29A9AE2


> On Mon, Jan 17, 2011 at 2:58 PM, Samuel Adam <[hidden email]> wrote:
>
>> I am seeking the lowest-overhead way to grab 24-bit audio straight from  
>> a
>> piece of 24-bit hardware.  The problem is, Sox is recording 16-bit  
>> samples
>> by default (although it does detect the sample rate correctly).  Adding
[snip]

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Reliable, Low-Overhead 24-bit Audio Capture on Windows

Samuel Adam-2
In reply to this post by Rüdiger Hausmann
On Tue, 18 Jan 2011 01:11:41 -0500, Rüdiger Hausmann  
<[hidden email]> wrote:

> Just to prevent irritations: sox *does* capture 24bit length native
> under linux, doesn't it?
> Rüdiger

I don’t know the answer to that; but I do know that my question concerns  
waveaudio.c, which is Windows-only:

http://sox.cvs.sourceforge.net/viewvc/sox/sox/src/waveaudio.c?revision=1.6&view=markup

As I understand it, Sox uses completely different means on Linux; and  
waveaudio.c was only added about 16 months ago to fill a functionality gap  
on Microsoft platforms.  My problem seems to originate in a limitation of  
earlier Windows/WINAPI versions, which Mr. Cook (author of waveaudio.c)  
quite understandably wishes to maintain compatibility with.

Very truly,

Samuel Adam <http://certifound.com/>
763 Montgomery Road
Hillsborough, NJ  08844-1304 • United States
ANNOUNCING: Adam v. Supreme Court of New Jersey, et al.
Complaint: http://certifound.com/+77AD29C
Media Letter (cf. Madoff!): http://certifound.com/+29A9AE2


> Am 18.01.2011 01:30, schrieb Doug Cook:
>> Sox is recording at 16 bits and converting the result to your
>> requested sample depth. The current waveaudio support is 16-bit only.
>> The hoops in WinAPI aren’t terribly great, but it added some
>> complexity regarding the detection of 24/32 bit support and
>> negotiating the "best" sample rate without introducing
>> incompatibilities with earlier versions of Windows.
>>
>> On Mon, Jan 17, 2011 at 2:58 PM, Samuel Adam <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     I am seeking the lowest-overhead way to grab 24-bit audio straight
>>     from a
>>     piece of 24-bit hardware.  The problem is, Sox is recording 16-bit
>>     samples
>>     by default (although it does detect the sample rate correctly).
[snip]

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Reliable, Low-Overhead 24-bit Audio Capture on Windows

Rob Sykes
In reply to this post by Rüdiger Hausmann
From: Rüdiger Hausmann <[hidden email]>
To: [hidden email]
Sent: Tue, 18 January, 2011 6:11:41
Subject: Re: [SoX-users] Reliable, Low-Overhead 24-bit Audio Capture on Windows

Just to prevent irritations: sox *does* capture 24bit length native under linux, doesn't it?
Rüdiger

Yes, with both OSS (captured as 32-bit) & ALSA, providing that this is supported by the underlying kernel driver for your sound hardware.

Rob



------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: Reliable, Low-Overhead 24-bit Audio Capture on Windows

Doug Cook-2
In reply to this post by Samuel Adam-2


On Tue, Jan 18, 2011 at 4:35 AM, Samuel Adam <[hidden email]> wrote:
On Mon, 17 Jan 2011 19:30:57 -0500, Doug Cook
<[hidden email]> wrote:

> Sox is recording at 16 bits and converting the result to your requested
> sample depth. The current waveaudio support is 16-bit only. The hoops in
> WinAPI aren't terribly great, but it added some complexity regarding the
> detection of 24/32 bit support and negotiating the "best" sample rate
> without introducing incompatibilities with earlier versions of Windows.

Thanks for the concise answer.  I see that you are evidently the author of
waveaudio.c.  Glancing through MSDN, unless I am wildly off-base, I
believe this sums up the problem:

http://msdn.microsoft.com/en-us/library/dd757714.aspx
 ------ begin quotation
       WAVEFORMATEXTENSIBLE Structure

       …higher sample resolutions than allowed by WAVEFORMATEX…

       Minimum supported client        Windows XP
       Minimum supported server        Windows Server 2003
       Header  Mmreg.h
 -------- end quotation

For the archives (and for anybody who wants to brave the maze of
2K/XP/Vista/7 audio API changes), I hope that provides a nudge in the
right direction.  By the way, kudos for keeping Windows 2000 compatibility.

As for me, it seems I’ll have to find something else.  It looks trivial to
whip up a dumb audio dumper for my needs using Steinberg’s ASIO API; I
guess I will need to go that route at some point.
It's not really a matter of backwards-compatibility... It's ok to use WAVEFORMATEXTENSIBLE on a Windows 2000 OS as long as your program is able to handle the error code and fall back to WAVEFORMATEX if the OS or sound card doesn't support WAVEFORMATEXTENSIBLE. It just makes the program logic a bit more complicated. For the first release of the waveaudio device, I wanted to be sure it was simple and correct, and 24-bit sound was deemed to be an unnecessary complexity, especially since I don't have any fancy audio equipment with which to test 24-bit support.
 
I took a few minutes and threw together a simple 24-bit-capable version of the waveaudio driver. You can give it a try if you want. If it works ok with your equipment, then I will check it in.
 
 
Give it a try and let me know if it works for you.

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

multiple output option?

Rüdiger Hausmann
In reply to this post by Samuel Adam-2
Hi,
the command
sox -b 32 -t alsa hw:0,0 -r 96000 -t alsa hw:0,0 --buffer 4096 biquad
0.1711450 -0.1460779 -0.0189046 1.0 -1.866608 0.8670383

captures an incoming soundstream from the first soundcard, applies RIAA
encoding, and sends the stream back to the card while forces its 24/96
full duplex capability.
Is there a possibility (preferably inside sox) to write a stereo 24/96
soundfile while keeping streaming to the card (alsa hw:0,0) at the very
same time?

Thanks,
Rüdiger

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: multiple output option?

Rüdiger Hausmann
would someone be so nice to help me on the horses' back how to duplicate
the output stream (inside or outside sox) to send it to alsa and store
it to a file at (roughly) the same time?
Rüdiger

Am 27.01.2011 17:58, schrieb Rüdiger Hausmann:

> Hi,
> the command
> sox -b 32 -t alsa hw:0,0 -r 96000 -t alsa hw:0,0 --buffer 4096 biquad
> 0.1711450 -0.1460779 -0.0189046 1.0 -1.866608 0.8670383
>
> captures an incoming soundstream from the first soundcard, applies RIAA
> encoding, and sends the stream back to the card while forces its 24/96
> full duplex capability.
> Is there a possibility (preferably inside sox) to write a stereo 24/96
> soundfile while keeping streaming to the card (alsa hw:0,0) at the very
> same time?
>
> Thanks,
> Rüdiger
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Sox-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/sox-users


------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: multiple output option?

Ulrich Klauer-2
Rüdiger Hausmann <[hidden email]>:

> how to duplicate
> the output stream (inside or outside sox) to send it to alsa and store
> it to a file at (roughly) the same time?

You could use JACK (jackaudio.org), I guess. It's not possible with plain SoX.

Ulrich

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: multiple output option?

Motiejus Jakštys
In reply to this post by Rüdiger Hausmann
2011/3/2 Rüdiger Hausmann <[hidden email]>:
> would someone be so nice to help me on the horses' back how to duplicate
> the output stream (inside or outside sox) to send it to alsa and store
> it to a file at (roughly) the same time?
> Rüdiger
Hello,
You may want to look at jack-audio-connection-kit

Motiejus Jakštys

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: multiple output option?

Chris Bagwell
In reply to this post by Ulrich Klauer-2
On Wed, Mar 2, 2011 at 3:40 PM, Ulrich Klauer <[hidden email]> wrote:
> Rüdiger Hausmann <[hidden email]>:
>
>> how to duplicate
>> the output stream (inside or outside sox) to send it to alsa and store
>> it to a file at (roughly) the same time?
>
> You could use JACK (jackaudio.org), I guess. It's not possible with plain SoX.
>

Yeah, Jack is probably your best bet although I think ALSA plugins
exist as well to do same (you'll have to google it as I do not know
off hand).

If your really set on SoX then you could try something like this:

sox infile -p | tee filename.sox | sox -p -d

Afterwards, you'll want to convert to a more typical file format:

sox filename.sox filename.mp3

Chris

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev 
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: multiple output option?

Rüdiger Hausmann
Am 02.03.2011 22:49, schrieb Chris Bagwell:
>
> sox infile -p | tee filename.sox | sox -p -d
>
I'm doing this for now, however, I get occasional over- and underruns
with the overruns being nasty (means noticable by ear).
Does sox makes use of real time kernel settings? The behaviour is the
same whether running with rt-privileges or not. (linux 2.6.33.7.2-rt30
#3 PREEMPT RT)
The machine uses an ancient Celeron 2.2 Ghz. The cpu load is under 20%,
though.

Is there something that can be done other than using jack as mentioned?

Rüdiger

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users
Reply | Threaded
Open this post in threaded view
|

Re: multiple output option?

Chris Bagwell
2011/5/15 Rüdiger Hausmann <[hidden email]>:

> Am 02.03.2011 22:49, schrieb Chris Bagwell:
>>
>> sox infile -p | tee filename.sox | sox -p -d
>>
> I'm doing this for now, however, I get occasional over- and underruns
> with the overruns being nasty (means noticable by ear).
> Does sox makes use of real time kernel settings? The behaviour is the
> same whether running with rt-privileges or not. (linux 2.6.33.7.2-rt30
> #3 PREEMPT RT)
> The machine uses an ancient Celeron 2.2 Ghz. The cpu load is under 20%,
> though.
>
> Is there something that can be done other than using jack as mentioned?
>

The only thing that can be done on sox side is to use the --buffer
option to adjust its size.  Larger will allow sox to buffer more input
data while hardware is processing the last buffer but will introduce
larger latency.

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Sox-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/sox-users