Maarten Lankhorst wrote:
>I think the key is to use accurate periods and report GetStreamLatency
>correctly.
You mentioned GSL in the past already, and I think it makes sense to return
real values instead of native's 10.6667 that I don't trust, however I expect
nothing from setting it:
http://bu
Hey Joerg,
Having actually finished the pulseaudio implementation and trying to fix some
fallout.
Op 29-02-12 16:28, joerg-cyril.hoe...@t-systems.com schreef:
> Hi,
>
> Maarten Lankhorst wrote:
>> For capture I plan to just add 2 queues, one for readable packets, and one
>> for packets that can
Hi,
Maarten Lankhorst wrote:
>For capture I plan to just add 2 queues, one for readable packets, and one
>for packets that can be filled for reading.
Winecoreaudio uses exactly this.
>... for the pulse driver, I'm using the auto timing
>update feature and the callback for when rendering is not r
Andrew Eikum wrote:
>And, not too surprisingly, TimerQueue isn't sufficient. I've attached
>my tests here. The tests ask to execute the callback every 12 ms. On
>my Windows 7 VM, I found that it executed with intervals like:
>20, 10, 10, 10, 10, 20, 10, 10, 10, 10, ...
>With an 11 occasionally int
Hi Andrew,
one small contribution:
> Winmm's timer functions use poll() with a timeout value, subtracting
> the time elapsed curing the callback. This works quite well in dsound.
>
> The Win32 API also provides the SetTimer API. But that depends on a
> message queue, which is a hassle I don't kno
On Tue, Feb 28, 2012 at 08:24:37AM -0600, Andrew Eikum wrote:
> I'm investigating native TimerQueue's operation now. If it turns out
> that TimerQueue isn't sufficient, we'll probably just switch over to
> using poll() like winmm's timer stuff does.
>
And, not too surprisingly, TimerQueue isn't s
On Mon, Feb 27, 2012 at 11:41:56PM +0100, Maarten Lankhorst wrote:
> > W.r.t. to 1.4.0, I believe the following path should be taken:
> > - Write CreateTimerQueue tests to verify whether native behaves like:
> > a) sleep(Xms) /* what Wine does now */ or
> > b) sleep(Xms - elapsed) /*
Hey Joerg,
Op 27-02-12 19:22, joerg-cyril.hoe...@t-systems.com schreef:
> Hi,
>
> Maarten Lankhorst wrote (partly in a former thread):
>
>>> R. thread priority -- no "Pro Audio" / Real-Time priority
>> Not going to happen, ever. AJ nuked all my attempts at it,
>> [...]
>> Or just fix things proper
Hi,
Maarten Lankhorst wrote (partly in a former thread):
>> R. thread priority -- no "Pro Audio" / Real-Time priority
>Not going to happen, ever. AJ nuked all my attempts at it,
>[...]
>Or just fix things properly and use rtkit for time critical threads
and now:
>I would say using rtkit for setti
Hey Joerg,
Op 24-02-12 13:28, joerg-cyril.hoe...@t-systems.com schreef:
> Hi,
>
> instead of Wine Weekly News (WWN, any taker?) you get monthly audio news.
>
> The surprising thing is: it looks like most audio bugs remaining in bugzilla
> are from the pre-mmdevapi era and have not been updated sin
On Friday, February 24, 2012 1:28:48 PM joerg-cyril.hoe...@t-systems.com
wrote:
>- https://bugs.freedesktop.org/show_bug.cgi?id=46296
> About the need to restart the PA server from time to time
>- https://bugs.freedesktop.org/show_bug.cgi?id=46297
> PA's huge buffering causes iss
On Fri, Feb 24, 2012 at 13:28, wrote:
> - https://bugs.freedesktop.org/show_bug.cgi?id=46297
This one is a question, not a bug, so should rather be asked on PA
official support channels TBH...
Frédéric
Hi,
instead of Wine Weekly News (WWN, any taker?) you get monthly audio news.
The surprising thing is: it looks like most audio bugs remaining in bugzilla
are from the pre-mmdevapi era and have not been updated since mid-2011.
- Using devices other than "default" (dmix or pulse):
#29294 no sound
On Fri, Jan 20, 2012 at 05:43:15PM +0100, joerg-cyril.hoe...@t-systems.com
wrote:
> #29294 no sound with ALSA loopback
> #28781 loopback to Jack
> It is not acceptable for winealsa to solely know "default" and "hw:x,y".
> The user can define and use any other name in the asound.conf files.
> The o
Hi,
Again, the list is quite different from what I posted last month,
partly because of a shift in focus.
The good news is: judging from bugzilla, audio seems to work
much better since 1.3.36/37.
#29294 no sound with ALSA loopback
#28781 loopback to Jack
It is not acceptable for winealsa to sole
Interesting,
It looks like bug #28982, could be affected by one or more of these you listed.
2011/12/16 :
> Hi,
>
> The present list is quite different from what I posted 2 month ago.
> http://www.winehq.org/pipermail/wine-devel/2011-October/092716.html
>
> #28723 is about handling tight timing a
Hi,
The present list is quite different from what I posted 2 month ago.
http://www.winehq.org/pipermail/wine-devel/2011-October/092716.html
#28723 is about handling tight timing and little prefill
#27901 is about snd_pcm_drop erroneously being used by AudioClient_Stop.
I've a patch in my queue b
On Fri, Oct 7, 2011 at 09:24, 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 underru
On Oct 7, 2011, at 9:24 AM, joerg-cyril.hoe...@t-systems.com wrote:
> 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
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
20 matches
Mail list logo
