[Live-devel] A question regarding the timing of doGetNextFrame

[Ben Rush]

Ross, in addition to the DWORD_PTR, the only feedback I'd have is to use

waveInPrepareHeader(shWaveIn, toRelease, sizeof(WAVEHDR));

instead of

toRelease->dwFlags &= ~WHDR_DONE;

In your releaseHeadBuffer() method. I imagine it's probably doing the same
 thing, but in the event anything changes under the hood, I'd let that
method handle header prep.

All in all I've got most of what we talked about resolved now. First off,
you were right, there was a blocking call (actually unbeknownst to me) in
my methods (I actually thought it wasn't blocking at first, so I learned
something). Once I resolved that and got everything asynchronous, audio and
video play fine now. With one weird exception.

The video appears to remain fine, but the audio gets unbelievably scratchy
once more than one client connects. With only one client, everything
streams and plays fine; with more than one (and it appears to grow worse
and worse as more clients grow), the audio starts to get scratchy, sort of
like a record player with a bad needle.

Do you have any idea what this could be about? Is there any particular
debugging code I can start injecting in places to get you more information
about what I'm seeing?

Thanks again for all your help,
Ben

On Mon, Feb 8, 2016 at 10:24 AM Ben Rush <ben at ben-rush.net> wrote:

> OK. I got into work just a bit ago and was going to check on your initial
> question
>
> "Was this the *only* change that you had to make here".
>
> But I believe it is. I will respond here in a couple hours with my final
> answer there, just in case.
>
> I totally appreciate why (I imagine most people using your product are
> doing so on Linux -- in fact, I've got a Linux distro using it myself), but
> given that I had to give a lot of love to the make files, etc. to get your
> stuff to build on Windows (to update it to the latest Visual Studio), I'm
> planning to basically create a Visual Studio 2015 solution that builds
> everything, pushing the source up on Github, and sharing it with you. My
> world is mostly Windows these days, but I have quite a bit of experience in
> developing for Linux, so I've got a lot of experience porting code between
> the two. When it's online I'll send you a link and you can run with it as
> you wish. Is that fair? It might not be for a couple days.
>
> On Mon, Feb 8, 2016 at 9:45 AM Ross Finlayson <finlayson at live555.com>
> wrote:
>
>> >> By the way, off topic (and I don't know if you care to know), but I
>> had to fix something in your waveInCallback method (in
>> WindowsAudioInputDevice_common). The callback method needs to have DWORD
>> parameters changed to DWORD_PTR to support 64-bit Windows.
>> >>
>> >> static void CALLBACK waveInCallback(HWAVEIN /*hwi*/, UINT uMsg,
>> >>    DWORD_PTR /*dwInstance*/, DWORD_PTR dwParam1, DWORD_PTR
>> /*dwParam2*/) {
>> >
>> > Thanks.  Was this the *only* change that you had to make here - i.e.,
>> change the three occurrences of “DWORD” to “DWORD_PTR” in the callback
>> function signature?  If so, then I’ll make this change in the next release
>> of the software.
>>
>> FYI, I wasn’t able to make this change in the released code, because
>> there are some (old?) versions of Windows ‘DevStudio’ out there for which
>> ‘DWORD_PTR’ is not defined.
>>
>>
>> Ross Finlayson
>> Live Networks, Inc.
>> http://www.live555.com/
>>
>>
>> _______________________________________________
>> live-devel mailing list
>> live-devel at lists.live555.com
>> http://lists.live555.com/mailman/listinfo/live-devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20160208/eb9961fc/attachment.html>