Quantcast
Channel: NAudio
Viewing all 5831 articles
Browse latest View live

Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]

$
0
0
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.

Comments: Not in the version I have (1.6) hHeader = GCHandle.Alloc(header); Constructor is public WaveInBuffer(IntPtr waveInHandle, Int32 bufferSize)

Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]

$
0
0
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.

Comments: OK, thought that had been in there for ages. Get the latest version then. It is very likely to be your issue. There's a pre-release build of 1.7 on Nuget if you want, or just build from latest sources

Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]

$
0
0
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.

Comments: Still fails but I feel like we are getting closer!

Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]

$
0
0
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.

Comments: fails in the same way?

New Post: Converting RTP Packets into wav format and writing to a wav file dynamically

$
0
0
Hello Mark,

I am trying to use naudio for a specific requirement in my current project. I am streaming RTP packets containing audio payloads over network via UDP. I want to convert these packets into wav format and write them into a wav file dynamically. I saw your code sample on Stack Overflow demonstrating how to convert RTP into wav. In my case if I store the entire RTP stream received over the network into a file and then use this file to generate a wav file using naudio APIs it works fine and creates a wav file that I can play. Here is the code that I am using:

WaveFormat waveformat = WaveFormat.CreateMuLawFormat(8000, 1);
        Stream tmpMemStream = new FileStream(@"C:\test11.txt", FileMode.Open, FileAccess.Read);
        var reader = new RawSourceWaveStream(tmpMemStream, waveformat);
        using (WaveStream convertedStream = WaveFormatConversionStream.CreatePcmStream(reader))
        {
            WaveFileWriter.CreateWaveFile(@"C:\output.wav", convertedStream);
        }
        tmpMemStream.Close();
However I want to convert the RTP packets into PCM stream dynamically that is as soon as I receive each set of RTP packets and write them immediately to a wav file. I want to initially create the wav file and then keep appending data to it as I receive the new RTP packets. Can you please suggest any APIs in naudio that I can use to achieve this functionality.

Thank you for your time.

Regards
Saleh

New Post: BufferedWaveProvider to Wavestream

$
0
0
Hi , I'm working on a project that applies some effects over some microphone input and I would like to be able to get that input to a wavestream. I tried using BufferedWaveProvider to send the input to the wavestream but it doesn't work.

Is there a way to achieve this? Some example would be helpful.

Thanks.

Created Unassigned: 32bit PCM into 16bit PCM [16397]

$
0
0
How can i convert 32 bit PCM wave into 16 bit PCM??

I was making software to record system volume using LoopBackCapture. Its capturing data of 32 bit PCM ( 32 bit PCM: 48kHz 2 channels wBitsPerSample:32 dwChannelMask:3 subFormat:00000003-0000-0010-8000-00aa00389b71 extraSize:22 )

I want to convert it into a 16 bit stereo data....I am not able to get it...

Its my code to convert the data from 32 bit PCM into 16 bit PCM. I am getting some noises and some real song data. Need help...

```
Private Function FX32TO16(ByVal input As Byte(), ByVal len As Integer) As Byte()
Dim output As Byte() = New Byte(len / 2 - 1) {}
Dim outputIndex As Integer = 0
For n As Integer = 0 To len - 1 Step 4
output(outputIndex) = input(n + 2)
output(outputIndex + 1) = input(n + 3)
outputIndex += 2
Next
Return output
End Function
```

Created Unassigned: Deadlock in Callback with WaveOut.GetPosition [16398]

$
0
0
I call WaveOut.GetPosition up to 60 times per second to sync an animation, and when using the Callback strategy, I get deadlocks very quickly (within 20-30 seconds) and consistently (all the time). I've [described the problem in more detail](http://stackoverflow.com/a/16468906/1174169) on Stack Overflow.

I made a change in WaveOut.Callback to delegate the work to the thread pool. I'm not sure if this is the best idea, as I'm not so familiar with the source of NAudio. Do you think this is a good idea? I've checked in the changes on [my NAudio fork](https://naudio.codeplex.com/SourceControl/network/forks/cod3monk3y/NAudio/changeset/1b3747e016b6).

I had to update the profile to 4.0 in order to use the `Task` class.

This solves the deadlock issue, and pretty much runs exactly the same way. The only difference (besides non deadlock) is that the thread running the callback isn't an OS thread. It's a thread pool thread.

Thanks!
/cm

Commented Unassigned: Deadlock in Callback with WaveOut.GetPosition [16398]

$
0
0
I call WaveOut.GetPosition up to 60 times per second to sync an animation, and when using the Callback strategy, I get deadlocks very quickly (within 20-30 seconds) and consistently (all the time). I've [described the problem in more detail](http://stackoverflow.com/a/16468906/1174169) on Stack Overflow.

I made a change in WaveOut.Callback to delegate the work to the thread pool. I'm not sure if this is the best idea, as I'm not so familiar with the source of NAudio. Do you think this is a good idea? I've checked in the changes on [my NAudio fork](https://naudio.codeplex.com/SourceControl/network/forks/cod3monk3y/NAudio/changeset/1b3747e016b6).

I had to update the profile to 4.0 in order to use the `Task` class.

This solves the deadlock issue, and pretty much runs exactly the same way. The only difference (besides non deadlock) is that the thread running the callback isn't an OS thread. It's a thread pool thread.

Thanks!
/cm
Comments: I strongly advise against using the function callback strategy. It is the source of endless deadlock issues as you have discovered and I am thinking of removing it from NAudio altogether. Either use Window callbacks if at all possible, or use WaveOutEvent instead.

Commented Unassigned: Deadlock in Callback with WaveOut.GetPosition [16398]

$
0
0
I call WaveOut.GetPosition up to 60 times per second to sync an animation, and when using the Callback strategy, I get deadlocks very quickly (within 20-30 seconds) and consistently (all the time). I've [described the problem in more detail](http://stackoverflow.com/a/16468906/1174169) on Stack Overflow.

I made a change in WaveOut.Callback to delegate the work to the thread pool. I'm not sure if this is the best idea, as I'm not so familiar with the source of NAudio. Do you think this is a good idea? I've checked in the changes on [my NAudio fork](https://naudio.codeplex.com/SourceControl/network/forks/cod3monk3y/NAudio/changeset/1b3747e016b6).

I had to update the profile to 4.0 in order to use the `Task` class.

This solves the deadlock issue, and pretty much runs exactly the same way. The only difference (besides non deadlock) is that the thread running the callback isn't an OS thread. It's a thread pool thread.

Thanks!
/cm
Comments: Thanks for the comment, Mark. I'm aware of the issues (clearly!) with the function callback strategy, [from your blog](http://mark-dot-net.blogspot.com/2011/05/naudio-audio-output-devices.html). It's just the only solution that works with our requirements. (Though not-deadlocking is certainly an implicit requirement!) We *were* using Window callbacks, but even with "new window" the audio stutters during major changes in layout in a WPF app. Since the work is posted to the windows message pump, it must not be making it out in time to fill the buffer properly. I'm sure we could probably tune the app, but it's a large code base that was written by a former employee. We tried increasing the `DesiredLatency` in window-strategy mode to ensure that there were 2-4 seconds of audio buffered which could get us through the transition. But this resulted in static playing back when the 2nd buffer was only partially full (short audio file) and other serious failures (like BSoD). I'd be happy to try WaveOutEvent, but I need access to the current playback position which is only available through WaveOut. Or am I missing something? Do you have any recommendations or pointers as to where I can get the current playback position using WaveOutEvent, or how to prioritize the messages using the New/Existing Window strategy so that the audio doesn't stutter? Thanks! /cm

Commented Unassigned: 32bit PCM into 16bit PCM [16397]

$
0
0
How can i convert 32 bit PCM wave into 16 bit PCM??

I was making software to record system volume using LoopBackCapture. Its capturing data of 32 bit PCM ( 32 bit PCM: 48kHz 2 channels wBitsPerSample:32 dwChannelMask:3 subFormat:00000003-0000-0010-8000-00aa00389b71 extraSize:22 )

I want to convert it into a 16 bit stereo data....I am not able to get it...

Its my code to convert the data from 32 bit PCM into 16 bit PCM. I am getting some noises and some real song data. Need help...

```
Private Function FX32TO16(ByVal input As Byte(), ByVal len As Integer) As Byte()
Dim output As Byte() = New Byte(len / 2 - 1) {}
Dim outputIndex As Integer = 0
For n As Integer = 0 To len - 1 Step 4
output(outputIndex) = input(n + 2)
output(outputIndex + 1) = input(n + 3)
outputIndex += 2
Next
Return output
End Function
```
Comments: WaveFloatTo16Provider is intended for this purpose (assuming your captured data is floating point rather than 32 bit int).

New Post: BufferedWaveProvider to Wavestream

$
0
0
why do you need a wavestream? WaveProvider is simply a non-repositionable wavestream.

Commented Unassigned: Deadlock in Callback with WaveOut.GetPosition [16398]

$
0
0
I call WaveOut.GetPosition up to 60 times per second to sync an animation, and when using the Callback strategy, I get deadlocks very quickly (within 20-30 seconds) and consistently (all the time). I've [described the problem in more detail](http://stackoverflow.com/a/16468906/1174169) on Stack Overflow.

I made a change in WaveOut.Callback to delegate the work to the thread pool. I'm not sure if this is the best idea, as I'm not so familiar with the source of NAudio. Do you think this is a good idea? I've checked in the changes on [my NAudio fork](https://naudio.codeplex.com/SourceControl/network/forks/cod3monk3y/NAudio/changeset/1b3747e016b6).

I had to update the profile to 4.0 in order to use the `Task` class.

This solves the deadlock issue, and pretty much runs exactly the same way. The only difference (besides non deadlock) is that the thread running the callback isn't an OS thread. It's a thread pool thread.

Thanks!
/cm
Comments: The person who contributed the position reporting only did it for WaveOut, not WaveOutEvent, but the same change could easily be made. It's something I should try to get in for NAudio 1.7. You can either make your own build, or make your own custom version of WaveOutEvent for now. I would stay away from function callbacks though. I tried for over 5 years to flush out all the possible deadlocks. It turns out to be very dependent on soundcard drivers. Some have no issues whatsoever, while other (Realtek is a major culprit) deadlock all over the place.

Source code checked in, #d77cc0a5391a

$
0
0
added the GetPosition method from WaveOut to WaveOutEvent as well

Source code checked in, #f1f1fe0ecb34

$
0
0
fixed a few compiler warnings in WMA code

Source code checked in, #e91d1a9fda25

$
0
0
fixed some more compiler warnings

Commented Unassigned: Deadlock in Callback with WaveOut.GetPosition [16398]

$
0
0
I call WaveOut.GetPosition up to 60 times per second to sync an animation, and when using the Callback strategy, I get deadlocks very quickly (within 20-30 seconds) and consistently (all the time). I've [described the problem in more detail](http://stackoverflow.com/a/16468906/1174169) on Stack Overflow.

I made a change in WaveOut.Callback to delegate the work to the thread pool. I'm not sure if this is the best idea, as I'm not so familiar with the source of NAudio. Do you think this is a good idea? I've checked in the changes on [my NAudio fork](https://naudio.codeplex.com/SourceControl/network/forks/cod3monk3y/NAudio/changeset/1b3747e016b6).

I had to update the profile to 4.0 in order to use the `Task` class.

This solves the deadlock issue, and pretty much runs exactly the same way. The only difference (besides non deadlock) is that the thread running the callback isn't an OS thread. It's a thread pool thread.

Thanks!
/cm
Comments: Good to know, thanks. I ended up simply copying the GetPosition() code over to WaveOutEvent and making my own build. Like you said, it was a trivial change. It works great. [Code is up on my fork](https://naudio.codeplex.com/SourceControl/network/forks/cod3monk3y/NAudio/changeset/fb15b8b25d49). Thanks!

Commented Unassigned: Deadlock in Callback with WaveOut.GetPosition [16398]

$
0
0
I call WaveOut.GetPosition up to 60 times per second to sync an animation, and when using the Callback strategy, I get deadlocks very quickly (within 20-30 seconds) and consistently (all the time). I've [described the problem in more detail](http://stackoverflow.com/a/16468906/1174169) on Stack Overflow.

I made a change in WaveOut.Callback to delegate the work to the thread pool. I'm not sure if this is the best idea, as I'm not so familiar with the source of NAudio. Do you think this is a good idea? I've checked in the changes on [my NAudio fork](https://naudio.codeplex.com/SourceControl/network/forks/cod3monk3y/NAudio/changeset/1b3747e016b6).

I had to update the profile to 4.0 in order to use the `Task` class.

This solves the deadlock issue, and pretty much runs exactly the same way. The only difference (besides non deadlock) is that the thread running the callback isn't an OS thread. It's a thread pool thread.

Thanks!
/cm
Comments: cool. I checked the same change in too since I happened to have the project loaded up. Would have pulled from your fork if I'd realised, but thanks anyway

Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]

$
0
0
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.

Comments: No - it doesn't fail in the same way.... We modified the WaveInBuffer so that the header handle is pinned - we believe this fixed the accessViolation exception. However we were then getting an occasional EngineExecution exception, which appears to be in the Callback handler in WaveIn. Sometimes the Callback is being called with either a null buffer, or a corrupt one (IsQueued = true, etc). We have modified the code such that the first thing the Callback handler does is check the recording flag, and abort if it is not set i.e. : ``` private void Callback(IntPtr waveInHandle, WaveInterop.WaveMessage message, IntPtr userData, WaveHeader waveHeader, IntPtr reserved) { if (message == WaveInterop.WaveMessage.WaveInData) { if (recording) { var hBuffer = (GCHandle)waveHeader.userData; var buffer = (WaveInBuffer)hBuffer.Target; ``` __This appears to have solved the issue__

Commented Unassigned: Occasional AccessViolation in WDMAUD.DRV [16396]

$
0
0
Under load, I am getting an occasional AccessViolation in WDMAUD.DRV, and my application is crashing.

Comments: Well glad you have found a solution. I'll put this on the list of things to investigate. There is already another bug someone reported here: https://naudio.codeplex.com/discussions/400962#post933371. I might try implementing an event callback model for recording at some point as that might prove more robust.
Viewing all 5831 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>