Quantcast

Fwd: Would you guys be interested in ...

classic Classic list List threaded Threaded
79 messages Options
1234
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: Would you guys be interested in ...

Vaughan Johnson
Administrator
Leland's made some progress with VS2012, and said I may post this.

Any reason not to do this? I've been wanting to get to WASAPI for a
while now.

- V


-------- Original Message --------
Subject: Would you guys be interested in ...
Date: Mon, 10 Dec 2012 22:59:29 -0600
From: Leland Lucius <[hidden email]>
To: Vaughan Johnson <[hidden email]>

... patches to support building with VS2012 and/or building the
portaudio WASAPI host?  I've a Windows 64-bit build going as well.

The WASAPI host gives less than 10ms (usually around 7ms) latency on our
machines here as measured using a "What U Hear" type of device.  That's
using shared mode.  Exclusive mode should be better though I haven't
tried it.  Source code comments state that that less than 20ms isn't
possible in shared mode, but either I'm doing something wrong or the
comment is wrong.

To get WASAPI to work, I pulled the latest "released" portaudio code,
fixed a problem with the WASAPI IsStopped()/IsActive() handling and
updated the project files to get it to build.

For the VS2012 stuff, it pretty much upgraded the project files just
fine, but there was a little problem in the Build Events, in the nyquist
rules, and a change to libflac to fix a version check.

The 64-bit version was a bit more involved and I'm not really convinced
it worked flawlessly, but things "seemed" to work fine.




------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Would you guys be interested in ...

Stevethefiddle
WASAPI support sounds good.
Could this be the "major feature" for Audacity 2.0.4?

Steve

On 14 December 2012 04:46, Vaughan Johnson <[hidden email]> wrote:

> Leland's made some progress with VS2012, and said I may post this.
>
> Any reason not to do this? I've been wanting to get to WASAPI for a
> while now.
>
> - V
>
>
> -------- Original Message --------
> Subject: Would you guys be interested in ...
> Date: Mon, 10 Dec 2012 22:59:29 -0600
> From: Leland Lucius <[hidden email]>
> To: Vaughan Johnson <[hidden email]>
>
> ... patches to support building with VS2012 and/or building the
> portaudio WASAPI host?  I've a Windows 64-bit build going as well.
>
> The WASAPI host gives less than 10ms (usually around 7ms) latency on our
> machines here as measured using a "What U Hear" type of device.  That's
> using shared mode.  Exclusive mode should be better though I haven't
> tried it.  Source code comments state that that less than 20ms isn't
> possible in shared mode, but either I'm doing something wrong or the
> comment is wrong.
>
> To get WASAPI to work, I pulled the latest "released" portaudio code,
> fixed a problem with the WASAPI IsStopped()/IsActive() handling and
> updated the project files to get it to build.
>
> For the VS2012 stuff, it pretty much upgraded the project files just
> fine, but there was a little problem in the Build Events, in the nyquist
> rules, and a change to libflac to fix a version check.
>
> The 64-bit version was a bit more involved and I'm not really convinced
> it worked flawlessly, but things "seemed" to work fine.
>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Would you guys be interested in ...

Leland (Audacity Team)
Reworking patch for VS2008 and trying to make it work for VS2008 and
VS2012.  Be there soon...

On 12/14/2012 7:23 AM, Steve the Fiddle wrote:

> WASAPI support sounds good.
> Could this be the "major feature" for Audacity 2.0.4?
>
> Steve
>
> On 14 December 2012 04:46, Vaughan Johnson <[hidden email]> wrote:
>> Leland's made some progress with VS2012, and said I may post this.
>>
>> Any reason not to do this? I've been wanting to get to WASAPI for a
>> while now.
>>
>> - V
>>
>>
>> -------- Original Message --------
>> Subject: Would you guys be interested in ...
>> Date: Mon, 10 Dec 2012 22:59:29 -0600
>> From: Leland Lucius <[hidden email]>
>> To: Vaughan Johnson <[hidden email]>
>>
>> ... patches to support building with VS2012 and/or building the
>> portaudio WASAPI host?  I've a Windows 64-bit build going as well.
>>
>> The WASAPI host gives less than 10ms (usually around 7ms) latency on our
>> machines here as measured using a "What U Hear" type of device.  That's
>> using shared mode.  Exclusive mode should be better though I haven't
>> tried it.  Source code comments state that that less than 20ms isn't
>> possible in shared mode, but either I'm doing something wrong or the
>> comment is wrong.
>>
>> To get WASAPI to work, I pulled the latest "released" portaudio code,
>> fixed a problem with the WASAPI IsStopped()/IsActive() handling and
>> updated the project files to get it to build.
>>
>> For the VS2012 stuff, it pretty much upgraded the project files just
>> fine, but there was a little problem in the Build Events, in the nyquist
>> rules, and a change to libflac to fix a version check.
>>
>> The 64-bit version was a bit more involved and I'm not really convinced
>> it worked flawlessly, but things "seemed" to work fine.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Time track improvements

Maarten Baert
In reply to this post by Stevethefiddle
I think I've fixed most of the problems related to time tracks now, so
here's another patch. Yes, it's large, I had to rewrite a lot of code to
make this work. What this patch does:

- Fix/workaround for issue with libsamplerate requiring a reset after
lastFlag has been set.
- Adds a vertical ruler to time tracks.
- Time track envelopes now store the time track value directly, rather
than a value between 0 and 1.
- Completely new Integral + IntegralOfInverse + SolveIntegralOfInverse
code in Envelope (needed to get better accuracy).
- Bugfix in TimeTrack::Init (not all values were copied).
- Save/load time track range.
- Fixed the horizontal ruler of the time track (it is now accurate).
- Fixed bug where the sound ends too early and/or extra silence is added
to the end.
- Fixed inaccuracy of the playback indicator line.
- Option to use a logarithmic display for time tracks (off by default).
- Option to use logarithmic interpolation for time tracks (on by default).

To do:
- Testing :). I had to make some changes to the playback and mix system,
this needs more testing to make sure there are no regressions.
- Make sure all this works correctly with the undo system (I don't quite
understand how it works, but it seems to be okay).
- Shouldn't the time track be deleted after 'mix and render'?
- Zooming in/out by clicking the vertical ruler of a time track is not
implemented yet.
- Currently the range of time tracks is limited to 13%-1200%. I don't
know what these values mean, are these correct? AFAIK libsamplerate can
do far more.
- Envelope needs more consistent minimum/maximum value handling.
Currently it uses a fixed range from 1e-7 to 2, this should be
adjustable and should be checked consistently (rather than limiting it
in some functions and ignoring it in others).
- Rescale time track envelope values after loading an old project so old
project files can still be loaded correctly.
- There's a graphical glitch when loading a project with a logarithmic
vertical ruler - the ruler is too wide and TrackPanel doesn't reserve
enough space for it. This would probably be fixed by calling Refresh()
after loading (I'm not sure where to do this though).

I can split this patch into smaller ones if really needed, but I'd
rather not do that because it's extra work that won't actually improve
anything.

Maarten Baert

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

patch-timetrack-improvements-2.txt (57K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Would you guys be interested in ...

Richard Ash (audacity-help)
In reply to this post by Stevethefiddle
On Fri, 14 Dec 2012 13:23:51 +0000
Steve the Fiddle <[hidden email]> wrote:

> WASAPI support sounds good.
> Could this be the "major feature" for Audacity 2.0.4?

I think that's the right time scale, i.e. 6 months time. It would be
nice to do upstream updates for all the other libraries as well
(libflac has emerged from hibernation and will probably release 1.3.0
at about the same point we have 2.0.3) to give a current library base.

If we can get some of the portaudio patches upstream as well, even
better.

Richard

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Would you guys be interested in ...

Leland Lucius-2
In reply to this post by Leland (Audacity Team)
On 12/14/2012 10:47 AM, Leland wrote:
> Reworking patch for VS2008

Here's the patches (man, I'm out of practice).

First off, you'll want to pull down the latest snapshot of portaudio and
replace the lib-src/portaudio-v19 fella.  I did not try getting WASAPI
working with the existing portaudio-v19 as I figured there's probably
been too many updates to bother.

The wasapi-project.patch makes changes to the portaudio project files to
allow building all 5 hostapis.  It currently has MME, KS, and WASAPI
turned on by default.  DS and ASIO only if the SDKs are present and the
DXSDK_DIR and ASIOSDK_DIR env vars are defined.

The wasapi-portmixer.patch does NOT add any additional mixer
functionality.  It contains an updated portaudio.patch and changes the
order of the includes in px_win_endpoint.c to get some PKEY_ GUIDs
defined properly.

The wasapi-fix.patch is a fix to portaudio's WASAPI code to correctly
report stream state.  This has been sent to the portaudio list (was
unsure of proper reporting procedure).



------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

wasapi-fix.patch (1K) Download Attachment
wasapi-portmixer.patch (25K) Download Attachment
wasapi-project.patch (37K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Would you guys be interested in ...

Leland (Audacity Team)
In reply to this post by Leland (Audacity Team)
On 12/14/2012 10:47 AM, Leland wrote:
> Reworking patch for VS2008

Here's the patches (man, I'm out of practice).

First off, you'll want to pull down the latest snapshot of portaudio and
replace the lib-src/portaudio-v19 fella.  I did not try getting WASAPI
working with the existing portaudio-v19 as I figured there's probably
been too many updates to bother.

The wasapi-project.patch makes changes to the portaudio project files to
allow building all 5 hostapis.  It currently has MME, KS, and WASAPI
turned on by default.  DS and ASIO only if the SDKs are present and the
DXSDK_DIR and ASIOSDK_DIR env vars are defined.

The wasapi-portmixer.patch does NOT add any additional mixer
functionality.  It contains an updated portaudio.patch and changes the
order of the includes in px_win_endpoint.c to get some PKEY_ GUIDs
defined properly.

The wasapi-fix.patch is a fix to portaudio's WASAPI code to correctly
report stream state.  This has been sent to the portaudio list (was
unsure of proper reporting procedure).




------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

wasapi-fix.patch (1K) Download Attachment
wasapi-portmixer.patch (25K) Download Attachment
wasapi-project.patch (37K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Would you guys be interested in ...

Leland (Audacity Team)
In reply to this post by Leland (Audacity Team)
And here's the VS2012 patch.  Just load up "audacity.sln" into VS2012,
let the conversion happen, exit VS2012, and apply this patch.  I imagine
that the same changes to the ny.rules could be made in the VS2008
project so that there'd be no need to do it when converting to VS2012,
but I haven't tried it.

Leland


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

vs2012.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Would you guys be interested in ...

Leland (Audacity Team)
In reply to this post by Vaughan Johnson
>
> The 64-bit version was a bit more involved and I'm not really convinced
> it worked flawlessly, but things "seemed" to work fine.
>
Any interest in this?  I'll work out the patch if desired, but it would
be VS2012 based.

Leland



------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Time track improvements

Gale
Administrator
In reply to this post by Maarten Baert
On Fri, Dec 14, 2012 at 5:05 PM, Maarten Baert
<[hidden email]> wrote:

> I think I've fixed most of the problems related to time tracks now, so
> here's another patch. Yes, it's large, I had to rewrite a lot of code to
> make this work. What this patch does:
>
> - Fix/workaround for issue with libsamplerate requiring a reset after
> lastFlag has been set.
> - Adds a vertical ruler to time tracks.
> - Time track envelopes now store the time track value directly, rather than
> a value between 0 and 1.
> - Completely new Integral + IntegralOfInverse + SolveIntegralOfInverse code
> in Envelope (needed to get better accuracy).
> - Bugfix in TimeTrack::Init (not all values were copied).
> - Save/load time track range.
> - Fixed the horizontal ruler of the time track (it is now accurate).
> - Fixed bug where the sound ends too early and/or extra silence is added to
> the end.
> - Fixed inaccuracy of the playback indicator line.
> - Option to use a logarithmic display for time tracks (off by default).
> - Option to use logarithmic interpolation for time tracks (on by default).
>
> To do:
> - Testing :). I had to make some changes to the playback and mix system,
> this needs more testing to make sure there are no regressions.
> - Make sure all this works correctly with the undo system (I don't quite
> understand how it works, but it seems to be okay).
> - Shouldn't the time track be deleted after 'mix and render'?
> - Zooming in/out by clicking the vertical ruler of a time track is not
> implemented yet.
> - Currently the range of time tracks is limited to 13%-1200%. I don't know
> what these values mean, are these correct? AFAIK libsamplerate can do far
> more.
> - Envelope needs more consistent minimum/maximum value handling. Currently
> it uses a fixed range from 1e-7 to 2, this should be adjustable and should
> be checked consistently (rather than limiting it in some functions and
> ignoring it in others).
> - Rescale time track envelope values after loading an old project so old
> project files can still be loaded correctly.
> - There's a graphical glitch when loading a project with a logarithmic
> vertical ruler - the ruler is too wide and TrackPanel doesn't reserve enough
> space for it. This would probably be fixed by calling Refresh() after
> loading (I'm not sure where to do this though).
>
> I can split this patch into smaller ones if really needed, but I'd rather
> not do that because it's extra work that won't actually improve anything.
>
> Maarten Baert

Thanks, Maarten.

I tried the patch on Windows and Ubuntu 12.04 (both using libresample)
but on both OS'es it crashes for me (segmentation fault) as soon as I
try and play an audio track with a time track present.

Steps:

1 New project 44100 Hz
2 Generate any tone
3 Add a Time Track
4 Press Play.


Gale

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Time track improvements

Rob Sykes
In reply to this post by Maarten Baert
> From: Maarten Baert <[hidden email]>
>To: [hidden email]
>Sent: Friday, 14 December 2012, 17:05
>Subject: [Audacity-devel]  Time track improvements
>
>I think I've fixed most of the problems related to time tracks now, so here's another patch. Yes, it's large, I had to rewrite a lot of code to make this work.

Just wondering, is a sinusoidal rate envelope possible/well-supported? (Might be useful to help correct for analogue tape/disc rotational errors.)

/Rob

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Time track improvements

Maarten Baert
In reply to this post by Gale

On 17/12/12 05:09, Gale Andrews wrote:
> Thanks, Maarten.
>
> I tried the patch on Windows and Ubuntu 12.04 (both using libresample)
> but on both OS'es it crashes for me (segmentation fault) as soon as I
> try and play an audio track with a time track present.
Sorry, I swapped RangeLower and RangeHigher when telling the resampler
the minimum and maximum resampling factor. libsamplerate didn't care so
I didn't see it before. After fixing that it works with libresample too.
New patch attached.

Maarten Baert

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

patch-timetrack-improvements-2.txt (57K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Would you guys be interested in ...

James Crook
In reply to this post by Vaughan Johnson
I've a vague notion there were some issues with the license for the free
version of VS2012,
that would mean at the least that any released Audacity exe had to be
compiled on a paid version.

FWIW I'm still on VC2008 Express and have seen no reason to change.

Anyone have more details?

--James.

On 14/12/2012 04:46, Vaughan Johnson wrote:

> Leland's made some progress with VS2012, and said I may post this.
>
> Any reason not to do this? I've been wanting to get to WASAPI for a
> while now.
>
> - V
>
>
> -------- Original Message --------
> Subject: Would you guys be interested in ...
> Date: Mon, 10 Dec 2012 22:59:29 -0600
> From: Leland Lucius <[hidden email]>
> To: Vaughan Johnson <[hidden email]>
>
> ... patches to support building with VS2012 and/or building the
> portaudio WASAPI host?  I've a Windows 64-bit build going as well.
>
> The WASAPI host gives less than 10ms (usually around 7ms) latency on our
> machines here as measured using a "What U Hear" type of device.  That's
> using shared mode.  Exclusive mode should be better though I haven't
> tried it.  Source code comments state that that less than 20ms isn't
> possible in shared mode, but either I'm doing something wrong or the
> comment is wrong.
>
> To get WASAPI to work, I pulled the latest "released" portaudio code,
> fixed a problem with the WASAPI IsStopped()/IsActive() handling and
> updated the project files to get it to build.
>
> For the VS2012 stuff, it pretty much upgraded the project files just
> fine, but there was a little problem in the Build Events, in the nyquist
> rules, and a change to libflac to fix a version check.
>
> The 64-bit version was a bit more involved and I'm not really convinced
> it worked flawlessly, but things "seemed" to work fine.
>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Would you guys be interested in ...

Gale
Administrator

| From James Crook <[hidden email]>
| Tue, 18 Dec 2012 17:50:18 +0000
| Subject: [Audacity-devel] Fwd: Would you guys be interested in ...

> I've a vague notion there were some issues with the license for the free
> version of VS2012,
> that would mean at the least that any released Audacity exe had to be
> compiled on a paid version.
>
> FWIW I'm still on VC2008 Express and have seen no reason to change.
>
> Anyone have more details?
>
> --James.
I've looked at the licence (attached) for VS Express 2012 for Windows
Desktop.

I see that:

 "You may not
 * modify or distribute the source code of any Distributable Code so
    that any part of it becomes subject to an Excluded License. An
    Excluded License is one that requires, as a condition of use,
    modification or distribution, that
** the code be disclosed or distributed in source code form; or
** others have the right to modify it."

But Microsoft seems to be defining that "distributable code" as
its own distributable code:

*  REDIST.TXT Files. You may copy and distribute the object code
    form of code listed on the REDIST list located at
    go.microsoft.com/fwlink/?LinkId=247624.

*  Sample Code. You may modify, copy, and distribute the source and
    object code form of code marked as “sample.”

*  Third Party Distribution. You may permit distributors of your
    programs to copy and distribute the Distributable Code as part of
    those programs.

So not a problem? I see no complaints about it on the web from a
quick search.




Gale

 

> On 14/12/2012 04:46, Vaughan Johnson wrote:
> > Leland's made some progress with VS2012, and said I may post this.
> >
> > Any reason not to do this? I've been wanting to get to WASAPI for a
> > while now.
> >
> > - V
> >
> >
> > -------- Original Message --------
> > Subject: Would you guys be interested in ...
> > Date: Mon, 10 Dec 2012 22:59:29 -0600
> > From: Leland Lucius <[hidden email]>
> > To: Vaughan Johnson <[hidden email]>
> >
> > ... patches to support building with VS2012 and/or building the
> > portaudio WASAPI host?  I've a Windows 64-bit build going as well.
> >
> > The WASAPI host gives less than 10ms (usually around 7ms) latency on our
> > machines here as measured using a "What U Hear" type of device.  That's
> > using shared mode.  Exclusive mode should be better though I haven't
> > tried it.  Source code comments state that that less than 20ms isn't
> > possible in shared mode, but either I'm doing something wrong or the
> > comment is wrong.
> >
> > To get WASAPI to work, I pulled the latest "released" portaudio code,
> > fixed a problem with the WASAPI IsStopped()/IsActive() handling and
> > updated the project files to get it to build.
> >
> > For the VS2012 stuff, it pretty much upgraded the project files just
> > fine, but there was a little problem in the Build Events, in the nyquist
> > rules, and a change to libflac to fix a version check.
> >
> > The 64-bit version was a bit more involved and I'm not really convinced
> > it worked flawlessly, but things "seemed" to work fine.
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> > Remotely access PCs and mobile devices and provide instant support
> > Improve your efficiency, and focus on delivering more value-add services
> > Discover what IT Professionals Know. Rescue delivers
> > http://p.sf.net/sfu/logmein_12329d2d
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

VS2012 Windows Desktop license.txt (22K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Time track improvements

Richard Ash (audacity-help)
In reply to this post by Maarten Baert
On Mon, 17 Dec 2012 14:28:14 +0100
Maarten Baert <[hidden email]> wrote:
> Sorry, I swapped RangeLower and RangeHigher when telling the
> resampler the minimum and maximum resampling factor. libsamplerate
> didn't care so I didn't see it before. After fixing that it works
> with libresample too. New patch attached.

OK, tested this on Linux, although not being a time track user I don't
really know what it did before (I tried to play with the unpatched
version, but it didn't work ...).

It all seems to work fine for me, and to my surprise, projects saved
with the patch re-open OK into the last stable release of Audacity
(although the time tracks get mangled, they didn't work before, so I'm
not worried. All other tracks load OK).

That being the case I've committed most of the patch with the
exceptions listed below (see googlecode / the -svn list if you want the
actual patch for any reason).

I agree with most of your FIX-ME comments, but that's no reason not to
add these changes in now.

Richard

Questions:
AudioIO.cpp
@@ -2604,7 +2608,8 @@
       // if we hit this code during the PortAudio callback.  To keep
       // things simple, we only write as much data as is vacant in
       // ALL buffers, and advance the global time by that much.
-      int commonlyAvail = GetCommonlyAvailPlayback();
+      // MB: subtract a few samples because the code below has
rounding errors
+      int commonlyAvail = GetCommonlyAvailPlayback() - 10;

       //
       // Determine how much this will globally advance playback time
Can you expand on which code has the rounding errors? I'm concerned we
are adding a bug case in which GetCommonlyAvailPlayback() returns a
value less than 10 samples ...

Do we really need the commented-out Envelope::Rescale() function? It
doesn't seem to be used anywhere. Not committed.

@@ -1199,7 +1200,9 @@
    //

    mPlaybackRingBufferSecs = 10.0;
-   mMaxPlaybackSecsToCopy = 4.0;
+   mMaxPlaybackSecsToCopy = 1.0;
+   // MB: I think using 4 seconds as mMaxPlaybackSecsToCopy is
    excessive, a lower value decreases the
+   // startup time (especially for time tracks)

This really seems to be an unrelated change, and without more testing
of the performance implications (will slow I/O machines still record
OK?) I'm unwilling to take it. Not committed.

Minor bugs:
* If I right-click on the time track, weird stuff happens, creating
  envelope points which aren't where I clicked! Is right-click supposed
  to do anything at all?
* You've left various bits of code commented out in the patch (mainly
  1-line methods and prototypes). I've removed these, if any matter
  please re-add them.
* Where you are documenting a method, please format the comments for
  Doxygen, so that the documentation makes it to the HTML docs as well
  as the source code. I've done this to some of yours.
* There are some places in AudioIO.cpp where you make whitespace-only
  changes to the file, which are just noise.
* I won't pretend to understand the changes in Envelope.cpp - I assume
  they are right as Time Tracks are the only users.

A few things usability wise (areas for improvement, not criticisms):
* I can't use the multi-tool (*, F6) to manipulate time tracks. I use
  this for more or less everything else, so it's annoying me!
* Not sure I like the way logarithmic interpolation is set in the track
  pop-down menu - in particular, it doesn't tell me what I get if I
  turn it off, as well as not scaling to more choices (there is a
  b-spline interpolator in Audacity already, might be quite useful).
  Could this be like Set Rate on an audio track - a sub-menu of options
  with a tick by the selected one?
* Does the reset-and-samples-left logic have to be #ifdefed to one
  resampler? Could we not do it for all resamplers even if not strictly
  required?

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Time track improvements

Maarten Baert
On 19/12/12 22:49, Richard Ash wrote:
> Can you expand on which code has the rounding errors? I'm concerned we
> are adding a bug case in which GetCommonlyAvailPlayback() returns a
> value less than 10 samples ...
The code below converts commonlyAvail into seconds (secsAvail).
secsAvail is then repeatedly reduced by 'deltat' seconds until it is
zero. In each iteration, 'deltat' is converted back to samples using
'lrint', which is just an optimized 'round()' as far as I understand.
All these samples are added together. The sum of these samples could be
larger than commonlyAvail. That's why I added that.

It's probably not the best way to fix it though. The number 10 is fairly
arbitrary. One thing that would definitely help is to use 'floor' rather
than 'round'/'lrint' so the number of samples can only go down, not up.
Now there's still the possibility of rounding errors in that floating
point division and multiplication, but at least the largest source of
rounding errors is gone.

If GetCommonlyAvailPlayback returns less than 10, then commonlyAvail and
secsAvail will be negative and nothing will happen (the code is already
checking that).
> Do we really need the commented-out Envelope::Rescale() function? It
> doesn't seem to be used anywhere. Not committed.
No, I forgot to clean that up. Initially I left it there because it
would be useful to rescale old project files after loading, but if we're
not going to do that, it's not needed.

> @@ -1199,7 +1200,9 @@
>      //
>
>      mPlaybackRingBufferSecs = 10.0;
> -   mMaxPlaybackSecsToCopy = 4.0;
> +   mMaxPlaybackSecsToCopy = 1.0;
> +   // MB: I think using 4 seconds as mMaxPlaybackSecsToCopy is
>      excessive, a lower value decreases the
> +   // startup time (especially for time tracks)
>
> This really seems to be an unrelated change, and without more testing
> of the performance implications (will slow I/O machines still record
> OK?) I'm unwilling to take it. Not committed.
This does not affect the amount of audio that is buffered, only the size
of the processing blocks used for mixing. The mixer always reads up to
mQueueMaxLen samples at a time, and mQueueMaxLen is set to 65536. This
is not affected by the processing block size. So I don't think I/O would
change in any way. And mMaxPlaybackSecsToCopy does not affect recording
AFAIK, only playback.

What it *does* change is the time it takes to produce the first block.
Since playback can't start until the first block has been produced, a
high value will increase the startup time (i.e. you press 'play' and you
have to wait 1-2 seconds before the sound actually plays, really
annoying). It's especially noticeable when time tracks are used because
they slow down the processing. Maybe you can leave it at 4.0, but set it
to 1.0 if (mTimeTrack != NULL)?

> Minor bugs:
> * If I right-click on the time track, weird stuff happens, creating
>    envelope points which aren't where I clicked! Is right-click supposed
>    to do anything at all?
No, it shouldn't do anything. I see it even happens when I right-click
other tracks after right-clicking the vertical ruler of the time track.
But the same happens in current stable version of audacity, even though
time tracks don't even have a vertical ruler, so it can't be one of my
changes. I suppose some mouse events (i.e. right click events) are being
forwarded to the time track when they shouldn't. It doesn't happen with
wave tracks because right-clicking their rules will just make the wave
track zoom out. I don't really know how that part of the code works
though, I didn't change it except for some scaling. I will try to fix it
though.
> * You've left various bits of code commented out in the patch (mainly
>    1-line methods and prototypes). I've removed these, if any matter
>    please re-add them.
They don't matter, I just forgot to clean them up.
> * Where you are documenting a method, please format the comments for
>    Doxygen, so that the documentation makes it to the HTML docs as well
>    as the source code. I've done this to some of yours.
Ok.
> * There are some places in AudioIO.cpp where you make whitespace-only
>    changes to the file, which are just noise.
It's not intentional, that's because I made changes or added debugging
code that I removed (improperly) later. I will try to avoid it in the
future.
> A few things usability wise (areas for improvement, not criticisms):
> * I can't use the multi-tool (*, F6) to manipulate time tracks. I use
>    this for more or less everything else, so it's annoying me!
It works fine for me. Can you give more specific steps to reproduce
this? I rarely use that tool myself.
> * Not sure I like the way logarithmic interpolation is set in the track
>    pop-down menu - in particular, it doesn't tell me what I get if I
>    turn it off, as well as not scaling to more choices (there is a
>    b-spline interpolator in Audacity already, might be quite useful).
>    Could this be like Set Rate on an audio track - a sub-menu of options
>    with a tick by the selected one?
Okay, that's easy to change.

I don't think supporting time tracks with B-splines is feasible though
(what order? second, third, or higher?). I would need to do the math for
IntegralOfInverse and SolveIntegralOfInverse again, and it was already
pretty difficult for linear and logarithmic. I just gave it a try,
second order may be possible but the formulas I'm getting are far more
complex than the other two, and third order seems impossible (I can't
even generate the formula).
> * Does the reset-and-samples-left logic have to be #ifdefed to one
>    resampler? Could we not do it for all resamplers even if not strictly
>    required?
libresample doesn't have a reset function AFAIK, so it wouldn't do
anything. You could destroy and recreate the resampler, but would that
be better? Maybe it would be useful for libsoxr though, is that code
finished yet?

Maarten Baert

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Time track improvements

Vaughan Johnson
Administrator
In reply to this post by Richard Ash (audacity-help)
Thanks, Maarten, and Richard for reviewing and committing it, and all
others for the discussion.
- V

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Time track improvements

Rob Sykes
In reply to this post by Maarten Baert
----- Original Message -----

> From: Maarten Baert <[hidden email]>
> To: [hidden email]
> Cc:
> Sent: Thursday, 20 December 2012, 0:57
> Subject: Re: [Audacity-devel] Time track improvements
>
> On 19/12/12 22:49, Richard Ash wrote:
>>  * Does the reset-and-samples-left logic have to be #ifdefed to one
>>     resampler? Could we not do it for all resamplers even if not strictly
>>     required?

As mentioned previously, here's the change that should fix the root cause of the libsamplerate lock-up (and which is resampler-agnostic):


--- src/Mix.cpp (revision 12076)
+++ src/Mix.cpp (working copy)
@@ -404,6 +404,7 @@
       endPos = track->TimeToLongSamples(endTime);
    }
 
+   bool looping = GetActiveProject()->mLastPlayMode == loopedPlay;
    while (out < mMaxOut) {
       if (*queueLen < mProcessLen) {
          memmove(queue, &queue[*queueStart], (*queueLen) * sampleSize);
@@ -461,7 +462,7 @@
       int outgen = pResample->Process(factor,
                                       &queue[*queueStart],
                                       thisProcessLen,
-                                      last,
+                                      last && !looping,

> libresample doesn't have a reset function AFAIK, so it wouldn't do
> anything. You could destroy and recreate the resampler, but would that
> be better? Maybe it would be useful for libsoxr though, is that code
> finished yet?

I hope that if the root cause is fixed, these issues should disappear.

Not sure that libsoxr will ever be finished :) since optimisation & the law of diminishing returns comes in to play here, but there's pending at the moment.

Cheers,
Rob

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Time track improvements

Rob Sykes
----- Original Message -----

> From: Rob Sykes <[hidden email]>
> of diminishing returns comes in to play here, but there's pending at the
> moment.


typo: ... nothing pending ...

------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Time track improvements

Richard Ash (audacity-help)
In reply to this post by Maarten Baert
On Thu, 20 Dec 2012 01:57:22 +0100
Maarten Baert <[hidden email]> wrote:

> On 19/12/12 22:49, Richard Ash wrote:
> > Can you expand on which code has the rounding errors? I'm concerned
> > we are adding a bug case in which GetCommonlyAvailPlayback()
> > returns a value less than 10 samples ...
> The code below converts commonlyAvail into seconds (secsAvail).
> secsAvail is then repeatedly reduced by 'deltat' seconds until it is
> zero. In each iteration, 'deltat' is converted back to samples using
> 'lrint', which is just an optimized 'round()' as far as I understand.
> All these samples are added together. The sum of these samples could
> be larger than commonlyAvail. That's why I added that.
>
> It's probably not the best way to fix it though. The number 10 is
> fairly arbitrary. One thing that would definitely help is to use
> 'floor' rather than 'round'/'lrint' so the number of samples can only
> go down, not up. Now there's still the possibility of rounding errors
> in that floating point division and multiplication, but at least the
> largest source of rounding errors is gone.
>
> If GetCommonlyAvailPlayback returns less than 10, then commonlyAvail
> and secsAvail will be negative and nothing will happen (the code is
> already checking that).
Ok, I can see the problem.

This is another form of a very widespread
inconsistency about whether positions are in seconds or samples at some
rate (in this context it's clear, in many others it isn't). There is
also a nasty bug waiting to happen in lots of other places (I don't
think here) when the number of samples overflows a 32-bit integer (which
is quite easy to achieve in practice).

I'm suspecting that we should be doing the whole block of calculations
in integer samples, not in floating point seconds. This would remove
the rounding conversions you are rightly concerned about, although it
would probably create new ones in converting other times into samples.

The attached patch seems to work fine for me, although I haven't tested
extensively. A more comprehensive version which removes some of the
floating point time member variables may be possible, I haven't looked.

I have a memory of problems converting time to samples in the past, and
someone writing a class to make it more robust, ensure that the samples
variables were big enough to take the result etc. This code should use
that if I'm right. Martyn?

I'm not ignoring the rest of your email, but splitting this bit off as
I've got to go now.

Richard
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

use-samples-not-seconds.patch (7K) Download Attachment
1234
Loading...