The major mmdevapi and winmm audio bugs

[Austin English]

On Fri, Oct 7, 2011 at 09:24,  <Joerg-Cyril.Hoehle at t-systems.com> wrote:
> Hi,
>
> Bugzilla admins, please set the 1.4 milestone on all bugs mentioned here.
>
> I'm not yet looking at dsound issues since I first want a correct
> foundation upon which to build to upper layers.
>
> o #28039 IAudioClock_GetPosition must ignore underruns (MacOS)
> Here I've no idea how to solve this.  My initial query remained unanswered:
> http://lists.apple.com/archives/coreaudio-api//2011/Sep/msg00024.html
> Ken?  Andrew's yesterday patch (using GetCurrentPadding) is an interim
> work-around.  GetPosition (speaker) is unrelated to padding which is
> solely about buffering.
>
> o #28093 GetCurrentPadding must slowly decrease (MacOS)
> may cause an app to play audio using a single buffer, causing
> underruns and audio drop outs.
>
> o #28056 Problems with sound under FreeBSD
> which became "blocking calls with OSS"
> recently addressed by Andrew.
>
> o snd_pcm_drop causes incorrect GetPosition after mmdevapi Stop
> which I believe to be the cause of:
> #27901 winmm tests timing out waiting for hevent after waveOutRestart
> May get solved by Andrew's work in:
> #28517 Pikachu Volleyball stops playing sound effects
>
> Every snd_pcm_drop and reset must be inspected with care w.r.t. its
> effect on GetPosition.  Wine must ensure that after playing ends,
> GetPosition == sum of written samples for both mmdevapi and winmm.
>
> o #27937 winmm kept busy playing silence after play finishes
> IIRC because winmm writes silence.  Once mmdevapi handles underruns
> correctly, my patch "winmm: Never write silence, mmdevapi must handle
> underruns." will become applicable:
> http://www.winehq.org/pipermail/wine-patches/2011-September/107108.html
>
> Playing silence causes:
> #28027 μ-law rendering with pauses and repetitions (MacOS)
> as well as presumably:
> #28413 Sound play in games and programs causes brief "pauses"
> at the time dsound used winmm prior to 1.3.29.
>
> o #28047 IAudioClock_GetPosition must not depend on buffering (ALSA/Pulse)
> ALSA must derive GetPosition from snd_pcm_delay, not snd_pcm_avail_update
>
>
> There are other issues not associated with a bug entry.  I'm off for
> vacation, but here's a snippet from my TODO list:
> - OSS GetPosition from DSP_GETODELAY
> - ALSA+OSS: ReleaseBuffer: check method ordering and max size
> - GetStreamLatency = Xms + SHAREDMODE:period
>  Stream latency is a static property of the audio graph's components.
> - wineoss GetStreamLatency must be constant, and SNDCTL_DSP_GETODELAY
>  is only usable once running
> - Check WHDR_BEGIN/ENDLOOP code and write tests
> - WINMM_GetPosition is simply written_frames, not even minus padding
>  (as the old alsa driver did), later use mmdevapi:GetPosition.
> - winmm PushData without IAC_Reset or last_clock_pos=0 in case of underrun
> - Investigate OSS4 underrun behaviour
> - Align wineOSS on newest ALSA code improvements
> - Submit CoreAudio memory leak fix to #28023; Write error handling patch
> - Check ALSA laptop suspend w.r.t. GetPosition
> - Add run-time consistency checks in renderer and
>  abort audio stream (GetData) upon trouble instead of hanging.
>
> and finally:
>
> - Test compatibility with native DSound and file bug if unusable.
> There are several reports in bugzilla mentioning that this work-around
> ceased to work since 1.3.25.  Loss of interoperability is not acceptable.
>
> Regards,
>        Jörg Höhle

Done. In the future, please post full urls, makes my job easier :).

I've also given you bug editing/confirming privileges in bugzilla.

Cheers,
Austin