removed all instances of lock(this) and replaced with a lock object, making sure Position set and Read were both protected
↧
Source code checked in, #df99b9e0df3a
↧
Edited Issue: Position set .. lock (this) { } [8072]
Just google lock this and there's plenty of explanation to go around. Short of it is that user of the class (eg. CLR) may lock the class too and cause a deadlock. The recommended approach are is private lock objects: object mylock = new object(); .... lock (mylock) { }
I ran into the WaveFileReader race condition again even with the Stream.Synchronized around the stream making it a SyncStream.
The way it happened is that while the PlayThread is doing it's thing and eventually accessing the file, in the GUI thread I had exposed the ability to use the stream Position. And it worked very nicely yesterday until I made some minor changes elsewhere and now it started breaking when reaching the end of the file.
So I tried the naive way of putting a lock around the read and the position but that only resulted in a deadlock when user was trying to set Position to be larger than filesize.
Summary: The way to go is probably do just like the framework. ie. no Stream.Synchronized that I suggested before and maybe even no locks in the Position code because they'll just fool the user into thinking he can call them from whatever thread when that's not the case. The necessary synchronization needs to happen on the client app because only he will ultimately know how the stuff is called.
I ran into the WaveFileReader race condition again even with the Stream.Synchronized around the stream making it a SyncStream.
The way it happened is that while the PlayThread is doing it's thing and eventually accessing the file, in the GUI thread I had exposed the ability to use the stream Position. And it worked very nicely yesterday until I made some minor changes elsewhere and now it started breaking when reaching the end of the file.
So I tried the naive way of putting a lock around the read and the position but that only resulted in a deadlock when user was trying to set Position to be larger than filesize.
Summary: The way to go is probably do just like the framework. ie. no Stream.Synchronized that I suggested before and maybe even no locks in the Position code because they'll just fool the user into thinking he can call them from whatever thread when that's not the case. The necessary synchronization needs to happen on the client app because only he will ultimately know how the stuff is called.
↧
↧
Commented Issue: Position set .. lock (this) { } [8072]
Just google lock this and there's plenty of explanation to go around. Short of it is that user of the class (eg. CLR) may lock the class too and cause a deadlock. The recommended approach are is private lock objects: object mylock = new object(); .... lock (mylock) { }
I ran into the WaveFileReader race condition again even with the Stream.Synchronized around the stream making it a SyncStream.
The way it happened is that while the PlayThread is doing it's thing and eventually accessing the file, in the GUI thread I had exposed the ability to use the stream Position. And it worked very nicely yesterday until I made some minor changes elsewhere and now it started breaking when reaching the end of the file.
So I tried the naive way of putting a lock around the read and the position but that only resulted in a deadlock when user was trying to set Position to be larger than filesize.
Summary: The way to go is probably do just like the framework. ie. no Stream.Synchronized that I suggested before and maybe even no locks in the Position code because they'll just fool the user into thinking he can call them from whatever thread when that's not the case. The necessary synchronization needs to happen on the client app because only he will ultimately know how the stuff is called.
Comments: has been resolved in the latest NAudio
I ran into the WaveFileReader race condition again even with the Stream.Synchronized around the stream making it a SyncStream.
The way it happened is that while the PlayThread is doing it's thing and eventually accessing the file, in the GUI thread I had exposed the ability to use the stream Position. And it worked very nicely yesterday until I made some minor changes elsewhere and now it started breaking when reaching the end of the file.
So I tried the naive way of putting a lock around the read and the position but that only resulted in a deadlock when user was trying to set Position to be larger than filesize.
Summary: The way to go is probably do just like the framework. ie. no Stream.Synchronized that I suggested before and maybe even no locks in the Position code because they'll just fool the user into thinking he can call them from whatever thread when that's not the case. The necessary synchronization needs to happen on the client app because only he will ultimately know how the stuff is called.
Comments: has been resolved in the latest NAudio
↧
Source code checked in, #46a236b1d89b
added extension methods to support easy conversion from IWaveProvider to ISampleProvider and to allow passing an ISampleProvider directly into IWavePlayer
↧
Source code checked in, #2622dc7aae9b
nuget package now contains the Windows Store DLL (needs testing)
↧
↧
Source code checked in, #5e4b664388d0
updating projects with missing changes from adding msbuild community tasks nuget package
↧
Reviewed: NAudio 1.6 (May 06, 2013)
Rated 5 Stars (out of 5) - NAudio is unbelievably great and should be acquired by Microsoft!
↧
Reviewed: NAudio 1.6 (May 06, 2013)
Rated 5 Stars (out of 5) - NAudio is unbelievably great and should be acquired by Microsoft!
Thank you Mark, you rock!
↧
New Post: Getting end of stream error when reading a stream using WavFileReader
Do you reposition the MemoryStream to 0 before passing it into the WaveFileReader?
↧
↧
Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.
Comments: I haven't got a 'stand alone' piece of code that reproduces this issue yet - Still working on producing a smaller test harness that produces the same result. However, the stack trace from exception is as follows: 0:000> !pe Exception object: 00f8dbd4 Exception type: System.AccessViolationException Message: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. InnerException: <none> StackTrace (generated): SP IP Function 00000000 00000000 UNKNOWN!NAudio.Wave.WaveInterop.waveInAddBuffer(IntPtr, NAudio.Wave.WaveHeader, Int32)+0x1 0012F048 04AC4529 UNKNOWN!NAudio.Wave.WaveInBuffer.Reuse()+0x59 0012F05C 04AC4796 UNKNOWN!NAudio.Wave.WaveIn.Callback(IntPtr, WaveMessage, IntPtr, NAudio.Wave.WaveHeader, IntPtr)+0x96 0012F09C 04AC3CDB UNKNOWN!NAudio.Wave.WaveWindow.WndProc(System.Windows.Forms.Message ByRef)+0x5b 0012F0B8 7B5870F3 System_Windows_Forms_ni!System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)+0x13 0012F0C0 7B587071 System_Windows_Forms_ni!System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)+0x31 0012F0D4 7B586FB6 System_Windows_Forms_ni!System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)+0x96 0012F2AC 7B5971FF System_Windows_Forms_ni!System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)+0x287 0012F348 7B596E2C System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)+0x16c 0012F3A0 7B596C81 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)+0x61 0012F3D0 7B52366D System_Windows_Forms_ni!System.Windows.Forms.Application.Run(System.Windows.Forms.Form)+0x31 0012F3E4 030F027A CallTouchWorkstation!Northgate.CallTouch.Rulebase.Program.Main(System.String[])+0x20a
Comments: I haven't got a 'stand alone' piece of code that reproduces this issue yet - Still working on producing a smaller test harness that produces the same result. However, the stack trace from exception is as follows: 0:000> !pe Exception object: 00f8dbd4 Exception type: System.AccessViolationException Message: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. InnerException: <none> StackTrace (generated): SP IP Function 00000000 00000000 UNKNOWN!NAudio.Wave.WaveInterop.waveInAddBuffer(IntPtr, NAudio.Wave.WaveHeader, Int32)+0x1 0012F048 04AC4529 UNKNOWN!NAudio.Wave.WaveInBuffer.Reuse()+0x59 0012F05C 04AC4796 UNKNOWN!NAudio.Wave.WaveIn.Callback(IntPtr, WaveMessage, IntPtr, NAudio.Wave.WaveHeader, IntPtr)+0x96 0012F09C 04AC3CDB UNKNOWN!NAudio.Wave.WaveWindow.WndProc(System.Windows.Forms.Message ByRef)+0x5b 0012F0B8 7B5870F3 System_Windows_Forms_ni!System.Windows.Forms.Control+ControlNativeWindow.OnMessage(System.Windows.Forms.Message ByRef)+0x13 0012F0C0 7B587071 System_Windows_Forms_ni!System.Windows.Forms.Control+ControlNativeWindow.WndProc(System.Windows.Forms.Message ByRef)+0x31 0012F0D4 7B586FB6 System_Windows_Forms_ni!System.Windows.Forms.NativeWindow.Callback(IntPtr, Int32, IntPtr, IntPtr)+0x96 0012F2AC 7B5971FF System_Windows_Forms_ni!System.Windows.Forms.Application+ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)+0x287 0012F348 7B596E2C System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)+0x16c 0012F3A0 7B596C81 System_Windows_Forms_ni!System.Windows.Forms.Application+ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)+0x61 0012F3D0 7B52366D System_Windows_Forms_ni!System.Windows.Forms.Application.Run(System.Windows.Forms.Form)+0x31 0012F3E4 030F027A CallTouchWorkstation!Northgate.CallTouch.Rulebase.Program.Main(System.String[])+0x20a
↧
Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.
Comments: thanks. I've code reviewed WaveInBuffer again, and I can't see any issues (the Header and Data buffer structures are both pinned appropriately). I wonder whether it can sometimes be possible for WaveInBuffer.Reuse to get called after WaveInBuffer.Dispose has been called? Although I would expect waveInUnprepareHeader to have failed in that instance.
Comments: thanks. I've code reviewed WaveInBuffer again, and I can't see any issues (the Header and Data buffer structures are both pinned appropriately). I wonder whether it can sometimes be possible for WaveInBuffer.Reuse to get called after WaveInBuffer.Dispose has been called? Although I would expect waveInUnprepareHeader to have failed in that instance.
↧
New Post: How to stop current playback and play another
I'm doing some QA tools for audio and it happended, that i started to use NAudio. So far, so nice, but i've one issue.
I'm displaying list of files in DataGridView with button for each of them to play it out. Button handler looks like this (right now, it's about to change i hope).
I'm displaying list of files in DataGridView with button for each of them to play it out. Button handler looks like this (right now, it's about to change i hope).
private void showFilesGrid_CellMouseClick(object sender, DataGridViewCellMouseEventArgs e)
{
if( showFilesGrid.Columns[e.ColumnIndex].Name == "fileAction")
{
string fullFileName = showFilesGrid.Rows[e.RowIndex].Cells["fullPathDataGridView"].Value.ToString();
WaveStream outputStream = new WaveFileReader(fullFileName);
WaveChannel32 volumeStream = new WaveChannel32(outputStream);
WaveOutEvent player = new WaveOutEvent();
player.Init(volumeStream);
player.Play();
}
} ↧
Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.
Comments: This could be related... We appear to sometimes get a WaveStillPlaying result when calling waveInUnprepareHeader - causing the recording to be terminated. Looks like the callback has been triggered with a buffer that is not really 'done'. Have you ever seen this before? I notice that the handler for this calls RaiseRecordingStopped after setting 'recording' to false - but what state will the sound card be in? i.e. is a call to waveInStop/Reset required when this occurs?
Comments: This could be related... We appear to sometimes get a WaveStillPlaying result when calling waveInUnprepareHeader - causing the recording to be terminated. Looks like the callback has been triggered with a buffer that is not really 'done'. Have you ever seen this before? I notice that the handler for this calls RaiseRecordingStopped after setting 'recording' to false - but what state will the sound card be in? i.e. is a call to waveInStop/Reset required when this occurs?
↧
↧
Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.
Comments: might be a good idea to try, although you should still call Dispose on the WaveIn which will do a waveInReset and waveInClose
Comments: might be a good idea to try, although you should still call Dispose on the WaveIn which will do a waveInReset and waveInClose
↧
New Post: How to stop current playback and play another
keep hold of your reference to WaveOutEvent as a member of your class, so you can stop it. It is usually best to then Dispose it, and create another one for playback.
↧
New Post: 10 band Equalizer
Hi Robert,
Did you create a 10-band EQ and have it work well with the nAudio library? I wouldn't mind having a copy if it is possible so I can use it with my program...
Paul
Did you create a 10-band EQ and have it work well with the nAudio library? I wouldn't mind having a copy if it is possible so I can use it with my program...
Paul
↧
New Post: Forking NAudio
Hi,
First of all, thank you all for this great project. Great piece of work indeed. I wish MSFT would officially support this project, I'm sure this is gonna happen sooner or later.
I downloaded NAudio and implemented some features.
First of all, thank you all for this great project. Great piece of work indeed. I wish MSFT would officially support this project, I'm sure this is gonna happen sooner or later.
I downloaded NAudio and implemented some features.
- Created an extensive Pitch class and accompanying enums to manipulate musical pitches and convert between verbal pitch (A0, Bb-1, G# etc.) and midi value.
- Inverted instrument list to enum
- Enumeration of drum types
-
Control note duration via sophisticated flags enum that converts verbal duration to midi code (Quarter Eight etc.)
- How can I have my fork hosted on CodePlex while using TFS as source control?
- Is it likely that my contributions will ever be committed to the official release or I will always remain chasing up the changes?
↧
↧
Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.
Comments: I had a look at WaveInBuffer - and noticed that the header is not pinned - should it be?
Comments: I had a look at WaveInBuffer - and noticed that the header is not pinned - should it be?
↧
Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.
Comments: Note: calling waveInStop when the callback is triggered with a Done=false buffer made no difference. I have modified the code to only .Reuse the buffer if the Buffer is not .InQueue. (I realise that I may run out of buffers!)
Comments: Note: calling waveInStop when the callback is triggered with a Done=false buffer made no difference. I have modified the code to only .Reuse the buffer if the Buffer is not .InQueue. (I realise that I may run out of buffers!)
↧
Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.
Comments: the header is pinned in the constructor. See the following code: ``` hHeader = GCHandle.Alloc(header, GCHandleType.Pinned); ```
Comments: the header is pinned in the constructor. See the following code: ``` hHeader = GCHandle.Alloc(header, GCHandleType.Pinned); ```
↧