Re: Waveform Audio - MMSYSERR_INVALPARAM

From: Almon B. Strowger (strowger_at_NOSPAM.kook.com)
Date: 03/18/05 

Date: Fri, 18 Mar 2005 04:37:22 -0800

Hi,

Pay attention to the things you have been told.

Anyway, you shouldn't waveOutWrite dozens of buffers
at a time--It should be "several" or "a handful."
You should go for attempting to maintain a count of
several buffers. You have to balance the issues of
network latency and CPU cycle starvation versus what
an unacceptable audio delay is. This is the hardest part.

You need to understand a few more concepts:
1. One of those concepts, as Robert stated several times,
is if you have an input samplerate that is even very slightly
higher than your output rate when they are nominally the
same, if you don't occasionally hiccup/skip on the output,
the data backup will CONTINUALLY INCREASE.

2. Also, packets/buffers that you waveOutWrite, are packets
that you are handing over to the system. You don't get to
mess with them/re-waveOutWrite them, until the system
has flushed them and "given" them back to you. You must
not ignore this, otherwise you will get anything from an error
every once in a while to errors all the time.

3. You also need to understand keeping the continuity of the
sample data--ie. The first sample from a buffer should come
right after the last sample from the previous buffer seamlessly.
This means you should always have more than one buffer
queued--And frankly more than 2, because there is a latency
from a buffer being flushed to when you are notified about it.
ie. Time goes by, so you are ALREADY playing the next buffer.

Given these, your errors are not surprising at all.

Hope this helps...

Almon B. Strowger
KOOK Pocket Software

"Black_angel" <Blackangel@discussions.microsoft.com> wrote in message
news:607CB333-AF2C-4F45-B498-564BB82C9491@microsoft.com...
> This is incredible, I'm very amazed...
>
> Doing tests I have seen where is the problem, but I don't understand.
> I have aThread that it's receiving packets from the other machine using
> Sockets, and it leaves them in a queue.
> This Thread has a loop, and it receive 2 packets every time. When the
> count's loop is in 152 (it has received 304 packets and it is waiting for
the
> packet 305) is when the waveOutWrite function returns the
MMSYSERR_INVALPARAM
> error!!!!
> Surprisingly, if when I receive the first packet I keep it and I don't
> use the "ReceiveFrom" function of the Sockets more (I use always the first
> packet that I kept) , the waveOutWrite function DON'T return the error.
> More surprisingly, if when I receive the first packet I keep it BUT I
> receive more packets from the socket that I DON'T USE (I continue using
the
> first packet)... the waveOutWrite function returns the error.
> I have tested to put a Sleep() function in the thread to emulate the
time
> that the packets take to arrive with the receiveFrom function. I have
tested
> to sleep a long time, don't sleep, and to sleep 100 milliseconds that it's
> the normal time that the packets have to take time. Without the
ReceiveFrom
> function of the Socket... the waveOutWrite function doesn't return any
error.
> In conclusion, if I receive packets from the Socket, even if I don't
use
> them, the waveOutWrite function returns the error.
>
>
> I don't know why. I'm really amazed.
>
> Regards.
>
>
> "Robert Scott" wrote:
>
> > On Thu, 17 Mar 2005 07:37:08 -0800, "=?Utf-8?B?QmxhY2tfYW5nZWw=?="
> > <Blackangel@discussions.microsoft.com> wrote:
> >
> > >Thanks,
> > >
> > >I'm developing an application for VoIP (Voice over IP).
> > >That is why I can't use streams, I use packets of bytes with time and
> > >sequence information that I send from a machine to the other machine
using
> > >Sockets.
> > >The audio's format is the same 11.025, 8 bits and 2 channels, and each
> > >packet has a number of bytes that it's the same than 100 milliseconds:
> > >bufferSize= ((ratio*bits*canales)/8)/10;
> > >
> > >I have a thread witch gets a packet of a queue (where other thread
witch
> > >manages the sockets sets the packets from the sender) every 100
milliseconds
> > >I used a CALLBACK_WINDOW too, but I had the same error.
> > >The problem is that when I send 100 packets (more or less) to the
> > >waveOutWrite function it returns the error MMSYSERR_INVALPARAM
> >
> > You are probably overrunning the sound driver buffering capacity. One
> > solution is to design your system so that the input rate (the average
> > rate of packets delivered over Sockets) is slightly slower than the
> > sound output rate. This will produce occasional "gaps" in the sound,
> > but it may not be noticeable.
> >
> > I don't think you are addressing the fundamental problem of differing
> > data rates. If you try to feed the sound system faster than it is
> > capable of swallowing, it is eventually going to throw up on you! And
> > that's what the MMSYSERR_INVALPARAM error is.
> >
> >
> > -Robert Scott
> > Ypsilanti, Michigan
> >

Relevant Pages

  • Re: WaveOutWrite and Sockets
    ... The time of the packets is 100 ms. ... Also, packets/buffers that you waveOutWrite, are packets ... >right after the last sample from the previous buffer seamlessly. ... >Almon B. Strowger ...
    (microsoft.public.pocketpc.developer)
  • Re: In-tree version of new FireWire drivers available
    ... Just to recap, the dual buffer receive mode, as described in section ... quadlet aligned amount of header data can be appended into one buffer ... *either* the header buffer or the payload buffer fills up. ... enough to hold headers for all the packets it takes to fill up the ...
    (Linux-Kernel)
  • Re: Persistent stall in the Cypress FX2 FIFO
    ... the FX2's firmware code, would be to install some sort of stub routines ... > how long they are (it appends even for 4 byte long packets). ... > a packet from the FIFO before sending the next one all works fine... ... smaller or larger than what a single buffer could hold. ...
    (comp.arch.embedded)
  • Re: Self restarting property of RTOS-How it works?
    ... >> paradigm that is susceptible to attacks as simple as buffer ... > computer science end of things, but I don't share your evident ... > that no packets will arrive in an interval of five seconds? ... Whatever the synchronizing requires, ...
    (comp.arch.embedded)
  • Re: Multicast Packet Delay
    ... the packets and stuffs them into the datalink layer. ... There's a buffer here of course, ... MTU of all network it traverses in order to avoid fragmenting ...
    (microsoft.public.win32.programmer.networks)