Re: [clusapi] Don't print an out parameter
On Wednesday 29 April 2009 10:08:56 am Paul Vriens wrote: Was going through some logs on Bugzilla and noticed this. Changelog Don't print an out parameter The spec entry for ClusterEnum also needs a fix. -Hans
Re: The DIB engine... does anyone know how to get it into Wine?
2009/4/29 Massimo Del Fedele m...@veneto.com: I didn't look at Direct3d 10, but I guess he don't affect zillions of apps, does it ? DX10 -- Vista, and (AFAIK) most DX apps still use 9. D3D10 itself isn't used that much yet, most current D3D10 applications also have a D3D9 renderer. However, our d3d10 is based on wined3d, which is also used by ddraw, d3d8 and d3d9. So wined3d has to keep working while d3d10 is being implemented. I don't know enough about the internal x11drv and gdi32 architecture to judge if the scale is the same, but I suppose the concept is somewhat similar. I would of course expect Alexandre to be much more strict wrt. winex11.drv than wined3d since it's a much more critical component. I'd also expect reputation / experience with winex11.drv and gdi32 to be taken into account. I.e., trust, if you like.
Re: gdiplus: partially implement GdipBitmapSetPixel
Massimo Del Fedele wrote: This one implements GdipBitmapSetPixel() besides unhandled alpha channel. Ciao Max +SetPixel(hdc, x, y, ((color 16) 0xff) | (color 0x00ff00) | ((color 16) 0xff)); Use ARGB2COLORREF(ARGB color) from gdiplus.c for that.
Re: The DIB engine... does anyone know how to get it into Wine?
Henri Verbeet ha scritto: I would of course expect Alexandre to be much more strict wrt. winex11.drv than wined3d since it's a much more critical component. of course :-) I'd also expect reputation / experience with winex11.drv and gdi32 to be taken into account. I.e., trust, if you like. I agree. That's why I've chosen the new approach. As a new driver it can't break anything, so it could (but I guess it won't) be introduced as an alternative display driver in parallel to winex11. Ciao Max
Re: The DIB engine... does anyone know how to get it into Wine?
On Wed, Apr 29, 2009 at 10:34 AM, Luke Benstead kaz...@gmail.com wrote: It would be nice to see what Alexandre's opinion of the options discussed in this thread is, as he's ultimately the one who will decide. From an observer's point of view, I'd say that moving the current DIB code out of wineX11 first before replacing it with Max's DIB code sounds like the cleanest idea, because then if any bugs are introduced it will be directly from the migration of the code, not the logic of the DIB stuff itself. But obviously, from reading the discussion, it's not as clean cut as just moving the code. Luke. Yesterday there was a discussion on IRC about the DIB engine. To summarize it someone with a deep understanding of gdi32 should write the DIB engine and the only one right now who he think is capable of that is Huw. But he has no time to work on it right now (if there was funding for lets say half a year or so there might be time). Another solution might be (although I'm not sure if Huw is interested in that) is for him to mentor some people in working on the DIB engine. He would document how the DIB engine should be implemented and how it should interact with other parts of Wine. Roderick
Re: Ubuntu no longer works correctly without pulseaudio
On Tue, Apr 28, 2009 at 10:52 PM, Ben Klein shackl...@gmail.com wrote: I'm still interested to know what the problem with purging pulseaudio is, as that is the current preferred solution that is given to users who have sound issues in #winehq. Apparently it keeps getting reinstalled. I encountered it yesterday when installing kernel updates and a few other things. I didn't bother to check what package is depending on it, only noticed it once my test results on http://test.winehq.org showed multiple failures in sound stuff. $ sudo apt-get remove --purge pulseaudio* worked for me. -- -Austin
Re: [3/3] iphlpapi: Add tests for GetAdaptersAddresses.
Hans Leidekker wrote:
diff --git a/dlls/iphlpapi/tests/iphlpapi.c b/dlls/iphlpapi/tests/iphlpapi.c
index 2fc5e0d..a03cc85 100644
+static void test_GetAdaptersAddresses(void)
+{
+ULONG ret, size;
+IP_ADAPTER_ADDRESSES *aa;
+IP_ADAPTER_UNICAST_ADDRESS *ua;
+
+if (!gGetAdaptersAddresses) return;
Could you add a win_skip()?
--
Cheers,
Paul.
Re: The DIB engine... does anyone know how to get it into Wine?
2009/4/29 Roderick Colenbrander thunderbir...@gmail.com: On Wed, Apr 29, 2009 at 10:34 AM, Luke Benstead kaz...@gmail.com wrote: It would be nice to see what Alexandre's opinion of the options discussed in this thread is, as he's ultimately the one who will decide. [Huw] would document how the DIB engine should be implemented and how it should interact with other parts of Wine. Honestly, I think getting some agreed-upon documentation up would be the most helpful thing. -- Chris
Re: The DIB engine... does anyone know how to get it into Wine?
2009/4/29 Chris Howe mrmess...@gmail.com: 2009/4/29 Roderick Colenbrander thunderbir...@gmail.com: On Wed, Apr 29, 2009 at 10:34 AM, Luke Benstead kaz...@gmail.com wrote: It would be nice to see what Alexandre's opinion of the options discussed in this thread is, as he's ultimately the one who will decide. [Huw] would document how the DIB engine should be implemented and how it should interact with other parts of Wine. Honestly, I think getting some agreed-upon documentation up would be the most helpful thing. -- Chris I agree. Luke.
Re: gdiplus: Implement GdipCreateHBITMAPFromBitmap
Massimo Del Fedele wrote:
Massimo Del Fedele ha scritto:
Should work for both DIBs and DDBs format, but strange enough the
IPicture bitmap
inside wine gdiplus bitmap is always a 32 bit DDB by now... haven't
found any
other case.
Ciao
Max
sorry again... another dumb copy/paste :-(
Former had a spurious FIXME used for debugging purposes
Max
+IPicture_get_Handle(bitmap-image.picture, (OLE_HANDLE*)hbm);
+if(!hbm)
+/* FIXME: return appropriate error code */
+return GenericError;
+
+/* gets bitmap data and find out bitmap's type */
+if(!(size = GetObjectW(hbm, sizeof(DIBSECTION), ds)))
+{
+ERR(Couldn't get bitmap data\n);
+return GenericError;
+}
Could be HICON here (see GdipCreateBitmapFromHICON) or metafile.
Since there's no tests for that could you please an explicit FIXME for
that types?
Re: try5 [4/4](resend) kernel32: Fix GetVolumeNameForVolumeMountPointW to match Mountmgr
Guy Albertelli galbe...@neo.rr.com writes: mountmgr.sys uses a specific format for unique volume name. Make GetVolumeNameForVolumeMountPointW match that format for the returned unique volume name. It should actually query mountmgr, not try to guess the name that mountmgr is using. -- Alexandre Julliard julli...@winehq.org
Re: gdiplus: Implement GdipCreateHBITMAPFromBitmap
Nikolay Sivov ha scritto:
Massimo Del Fedele wrote:
Massimo Del Fedele ha scritto:
Should work for both DIBs and DDBs format, but strange enough the
IPicture bitmap
inside wine gdiplus bitmap is always a 32 bit DDB by now... haven't
found any
other case.
Ciao
Max
sorry again... another dumb copy/paste :-(
Former had a spurious FIXME used for debugging purposes
Max
+IPicture_get_Handle(bitmap-image.picture, (OLE_HANDLE*)hbm);
+if(!hbm)
+/* FIXME: return appropriate error code */
+return GenericError;
+
+/* gets bitmap data and find out bitmap's type */
+if(!(size = GetObjectW(hbm, sizeof(DIBSECTION), ds)))
+{
+ERR(Couldn't get bitmap data\n);
+return GenericError;
+}
Could be HICON here (see GdipCreateBitmapFromHICON) or metafile.
Since there's no tests for that could you please an explicit FIXME for
that types?
Done, thank you for the hint :-)
Ciao
Max
Re: The DIB engine... does anyone know how to get it into Wine?
On Wed, Apr 29, 2009 at 6:51 AM, Luke Benstead kaz...@gmail.com wrote: I agree. Ditto. I made this point on IRC yesterday. No major project can move forward without a documented design and requirements. Unless these are forthcoming the DIB engine discussions are just going to keep amounting to noise with no signal. Thanks -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Sound problems with latest kernel -- formerly a pulseaudio thread but not any more
I'm changing the name of the thread. Pulseaudio has nothing to do with my current problem. I thought it did back when I started the thread, but my testing turned out to be incomplete. I still don't know what the problem is, but I believe it has to do with the way wine relates to the current Ubuntu configuration. Using the most current kernel, the most current updates (and using tomorrow's kernels and updates) dmix and dsnoop I believe are not recognized properly by wine because I'm not getting any sound through them. And I did file a bug, but I filed it back when I still thought it was a wine regression, so it's been a long and painful process of discovery. I have tested the following and I believe found they were not the problem: (1) wine regression: (2) problem with my experimental sound drivers; (3) problem with pulseaudio; (4) bizarre problem unique to me -- and for this I reinstalled the system an tested with the base before moving on. When I did the last install, with the current Ubuntu Studio, I got the same result using the downloaded Generic kernel. (Studio can use both Generic and Real-time kernels. Linux-rt didn't work for other reasons. It crashed on bootup.) I was informed that both then-current kernels had problems. So I got the linux-generic with current Ubuntu patches and a successful re-compile of the linux-rt without Ubuntu patches. And I still have exactly the same problem. Here are my current kernels: linux-rt: 2.6.29.1-rt8-custom (It doesn't include Ubuntu's patches.) linux-generic 2.6.28-12 (this is from the Ubuntu site and has Ubuntu's patches) When I run audacity through wine, I get the following input choices: MIME: Wine wave in mapper - Input MIME: dsnoop:Generic MIME: dsnoop:Generic Windows DirectSound: Primary Sound Capture Driver Windows DirectSound: dsnoop:Generic Windows DirectSound: dsnoop:Generic When I use the second option (MME: dsnoop:Generic) it works on the first pass, but when I try to stop and start it again -- no go. The second recording area pops up but it seems to shimmer. The recording meter does not move. And then it freezes. (That is approximately what happens to me training DNS.) When I use the 5th option (Windows DirectSound: dsnoop:generic) it works on the first pass, but when I stop/start it I get the following error message: Error when opening sound device. Please check the input device settings and the project sample rate.
Re: kernel32: Send exception information to winedbg for display in the crash dialog
Paul Chitescu pa...@voip.null.ro writes: Changelog: kernel32: Send exception information to winedbg for display in the crash dialog That info (and more) can be determined by the debugger itself, there's no need to pass it from kernel32. -- Alexandre Julliard julli...@winehq.org
Mmap/malloc redirection (bug 13335, seems to affect 3D games mainly)
Bug 13335 [1] is basically OpenGL games crash or run slow. There's two symptoms here, and they're to do with proprietary video drivers. When the nVidia driver fails to mmap stuff from /dev/nvidia0, it starts failing OpenGL commands with GL_OUT_OF_MEMORY. When the FireGL driver fails to mmap or malloc (I don't know which), it falls back to indrect rendering. The problem in both cases is because Wine mmaps most of the 32-bit memory space for itself and then parcels this back out through HeapAlloc and related methods. When the GL libraries calls mmap and malloc themselves, for quite large blocks of memory, they fail because there's nowhere in the address space for those large blocks of memory to go. The first linked patch [2] in bug 13335 fixes this by redirecting mmap calls into ntdll which unmaps a block of address space, and performs the mmap into that address space, effectively handing that address space over to the library for the duration of the mmap's existence. I can't claim credit for that, I merely took Thunderbird's forward-ported version of Alexandre's original patch and forward-ported it further to 1.1.19. The second linked patch [3] simply redirects malloc and related calls to RtlAllocateHeap, rather like the msvcrt malloc-type calls are handled. The latter's almost certainly in the wrong place in ntdll, but it keeps ntdll from needing two copies of the pthread_functions structure. The bug's staring to accumulate some feedback that this helps for games that otherwise tend to crash after playing for a little while, and I've not had any luck catching people on IRC to look over the patches, so I'm wondering if anyone would like to provide feedback on these patches, as to whether they are the right approach, and if there are things that could be handled more cleanly. [1] http://bugs.winehq.org/show_bug.cgi?id=13335 [2] http://bugs.winehq.org/attachment.cgi?id=20483 [3] http://bugs.winehq.org/attachment.cgi?id=20484 -- --- Paul TBBle Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) paul.hamp...@pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Marcus Brigstocke http://www.marcusbrigstocke.com/pacman.asp License: http://creativecommons.org/licenses/by/2.5/au/ --- pgplDEM0x9ZBo.pgp Description: PGP signature
Re: Sound problems with latest kernel -- formerly a pulseaudio thread but not any more
2009/4/29 Susan Cragin susancra...@earthlink.net: I have tested the following and I believe found they were not the problem: --snip-- (3) problem with pulseaudio How did you determine this? I thought you said your version of Ubuntu was crippled if pulseaudio was removed, so did you use pasuspender? If so, did you verify there was no pulseaudio process running while you were testing Wine?
Re: GL_APPLE_FENCE shares the same token in dlls/wined3d_gl.h with GL_FENCE_STATUS_NV.
2009/4/28 ace102 mgav...@juno.com: Hi, I noticed GL_APPLE_FENCE shares the same token in dlls/wined3d_gl.h with GL_FENCE_STATUS_NV. GL_FENCE_STATUS_NV http://www.opengl.org/registry/specs/NV/fence.txt Currently 0x84F3 GL_APPLE_FENCE http://www.opengl.org/registry/specs/APPLE/fence.txt Currently 0x84F3 Should be 0x8A0B from documentation. Is this by design or just something that slipped through the cracks? Thought I should alert someone just in case.:) Thanks. - Error:Success -- View this message in context: http://www.nabble.com/GL_APPLE_FENCE-shares-the-same-token-in-dlls-wined3d_gl.h-with-GL_FENCE_STATUS_NV.-tp23261485p23261485.html Sent from the Wine - Devel mailing list archive at Nabble.com. Is it just me or did this message get sent three times? :P
Re: Sound problems with latest kernel -- formerly a pulseaudio thread but not any more
2009/4/29 Susan Cragin susancra...@earthlink.net: I have tested the following and I believe found they were not the problem: --snip-- (3) problem with pulseaudio How did you determine this? I thought you said your version of Ubuntu was crippled if pulseaudio was removed, so did you use pasuspender? If so, did you verify there was no pulseaudio process running while you were testing Wine? After I started my testing, I did run into problems when I tried to re-install pulseaudio and then remove it, but the PA problem was unrelated. Ubuntu said there was a PA bug, and issued a fix. After I applied the fix, no more problems working with pulseaudio removed. So the whole thing was sort of a red herring. I have re-installed my entire system since that problem went away, and immediately purged pulseaudio, and that's where I'm working from now. Still same problem. Susan
Re: try5 [1/4](resend) kernel32/tests: Add tests for GetVolumeInformationA and QueryDosDevice
Guy Albertelli wrote: Fixed memory leak and changed skip to win_skip in this patch. Add todo_wine as necessary so all tests pass. Changelog: - Enhance QueryDosDevice test for attempting to return all devices. - Add tests for GetVolumeInformationA testing the different root dir formats. --- dlls/kernel32/tests/volume.c | 138 - 1 files changed, 134 insertions(+), 4 deletions(-) One of the tests fails on all W2K, XP and W2K3 boxes (no Vista results yet): http://test.winehq.org/data/tests/kernel32:volume.html Could you have a look? There is also a lot of trace/debugging information coming from these new tests. Is this needed? -- Cheers, Paul.
Re: Sound problems with latest kernel -- formerly a pulseaudio thread but not any more
2009/4/30 Susan Cragin susancra...@earthlink.net: 2009/4/29 Susan Cragin susancra...@earthlink.net: I have tested the following and I believe found they were not the problem: --snip-- (3) problem with pulseaudio How did you determine this? I thought you said your version of Ubuntu was crippled if pulseaudio was removed, so did you use pasuspender? If so, did you verify there was no pulseaudio process running while you were testing Wine? After I started my testing, I did run into problems when I tried to re-install pulseaudio and then remove it, but the PA problem was unrelated. Ubuntu said there was a PA bug, and issued a fix. After I applied the fix, no more problems working with pulseaudio removed. So the whole thing was sort of a red herring. I have re-installed my entire system since that problem went away, and immediately purged pulseaudio, and that's where I'm working from now. Still same problem. OK, thanks for that clarification. So you've tracked the problem down to kernel version 2.6.29? What version of ALSA drivers are in your working and broken kernels?
Re: Sound problems with latest kernel -- formerly a pulseaudio thread but not any more
I have tested the following and I believe found they were not the problem: --snip-- (3) problem with pulseaudio How did you determine this? I thought you said your version of Ubuntu was crippled if pulseaudio was removed, so did you use pasuspender? If so, did you verify there was no pulseaudio process running while you were testing Wine? After I started my testing, I did run into problems when I tried to re-install pulseaudio and then remove it, but the PA problem was unrelated. Ubuntu said there was a PA bug, and issued a fix. After I applied the fix, no more problems working with pulseaudio removed. So the whole thing was sort of a red herring. I have re-installed my entire system since that problem went away, and immediately purged pulseaudio, and that's where I'm working from now. Still same problem. OK, thanks for that clarification. So you've tracked the problem down to kernel version 2.6.29? What version of ALSA drivers are in your working and broken kernels? I've actually tracked it to before that. Wine's audio last worked with one of Ubuntu's generic kernels, probably 2.6.28-10. Ubuntu's current repository kernel is 2.6.28-11. That's the one I that caused the problem. The experimental bug-fix kernel is 2.6.28-12. That does not solve my problem. (Here's where I got the kernel: http://kernel.ubuntu.com/~dtchen/test-kernels/ ) When my kernel worked, my drivers were 0.1.19 -- one of Tashaki Iwai's daily stable builds from a couple of weeks ago. They are 0.1.19 now, today's daily stable build, compiled against 2.6.29-1-rt8-custom, which is what I am running at the moment. My 29-rt kernel is showing the same problems as the two kernels mentioned above. FWIW, the person who compiled the RT kernel said that he did so without applying the Ubuntu patches. So that tells me that the change took place outside the Ubuntu patches.
Re: GL_APPLE_FENCE shares the same token in dlls/wined3d_gl.h with GL_FENCE_STATUS_NV.
Is it just me or did this message get sent three times? :P 3 times for me too.
Re: try5 [1/4](resend) kernel32/tests: Add tests for GetVolumeInformationA and QueryDosDevice
On Wed, 2009-04-29 at 18:42 +0200, Paul Vriens wrote: Guy Albertelli wrote: Fixed memory leak and changed skip to win_skip in this patch. Add todo_wine as necessary so all tests pass. Changelog: - Enhance QueryDosDevice test for attempting to return all devices. - Add tests for GetVolumeInformationA testing the different root dir formats. --- dlls/kernel32/tests/volume.c | 138 - 1 files changed, 134 insertions(+), 4 deletions(-) One of the tests fails on all W2K, XP and W2K3 boxes (no Vista results yet): http://test.winehq.org/data/tests/kernel32:volume.html Could you have a look? There is also a lot of trace/debugging information coming from these new tests. Is this needed? Will find and fix. Thanks Guy
Re: try5 [1/4](resend) kernel32/tests: Add tests for GetVolumeInformationA and QueryDosDevice
Paul Vriens wrote: Guy Albertelli wrote: Fixed memory leak and changed skip to win_skip in this patch. Add todo_wine as necessary so all tests pass. Changelog: - Enhance QueryDosDevice test for attempting to return all devices. - Add tests for GetVolumeInformationA testing the different root dir formats. --- dlls/kernel32/tests/volume.c | 138 - 1 files changed, 134 insertions(+), 4 deletions(-) One of the tests fails on all W2K, XP and W2K3 boxes (no Vista results yet): http://test.winehq.org/data/tests/kernel32:volume.html Could you have a look? There is also a lot of trace/debugging information coming from these new tests. Is this needed? So everything as of W2K has the same error: volume.c:342: Test failed: GetVolumeInformationA failed, root=something, last error=123 On Win98 we also have some failures but for QueryDosDevice: volume.c:46: Test failed: QueryDosDevice buffer too small volume.c:52: Test failed: QueryDosDeviceA failed to return list, last error 87 Looks like Win98 doesn't like the NULL parameter passed to QueryDosDevice? Win95 doesn't have QueryDosDevice and sets last error to ERROR_CALL_NOT_IMPLEMENTED. -- Cheers, Paul.
Re: kernel32: Send exception information to winedbg for display in the crash dialog
On Wednesday 29 April 2009 18:02:17 Alexandre Julliard wrote: Paul Chitescu pa...@voip.null.ro writes: Changelog: kernel32: Send exception information to winedbg for display in the crash dialog That info (and more) can be determined by the debugger itself, there's no need to pass it from kernel32. True, but that would mean replicating the code in except.c format_exception_msg(). Getting the two pieces of code out of sync would cause user confusion as some will report the string displayed in the crash window while others will report the message from start_debugger(). I have also concerns about the message box that is displayed inside start_debugger() if the debugger is not to be started automatically - is it safe to assume the process is still capable to run the message loop for the window? Paul Chitescu
Re: winedbg: Accept a 3rd parameter to --auto to be used as extra info in the crash dialog
Paul Chitescu a écrit : Changelog: winedbg: Accept a 3rd parameter to --auto to be used as extra info in the crash dialog Next patch will actually send this info to the debugger from kernel32. this is not necessary to pass the information to winedbg, everything's needed is accessible from winedbg see tgt_active.c / dbg_handle_exception A+ -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Re: try5 [1/4](resend) kernel32/tests: Add tests for GetVolumeInformationA and QueryDosDevice
Guy Albertelli wrote: On Wed, 2009-04-29 at 18:42 +0200, Paul Vriens wrote: Guy Albertelli wrote: Fixed memory leak and changed skip to win_skip in this patch. Add todo_wine as necessary so all tests pass. Changelog: - Enhance QueryDosDevice test for attempting to return all devices. - Add tests for GetVolumeInformationA testing the different root dir formats. --- dlls/kernel32/tests/volume.c | 138 - 1 files changed, 134 insertions(+), 4 deletions(-) One of the tests fails on all W2K, XP and W2K3 boxes (no Vista results yet): http://test.winehq.org/data/tests/kernel32:volume.html Could you have a look? There is also a lot of trace/debugging information coming from these new tests. Is this needed? Will find and fix. Thanks Guy Just saw your patch, thanks. -- Cheers, Paul.
Re: kernel32: Send exception information to winedbg for display in the crash dialog
Paul Chitescu pa...@voip.null.ro writes: True, but that would mean replicating the code in except.c format_exception_msg(). Getting the two pieces of code out of sync would cause user confusion as some will report the string displayed in the crash window while others will report the message from start_debugger(). I don't think that's a problem at all. Plus to do this right you need the real info, not just a string. For instance we most likely want a completely different message box for stub exceptions, we don't want a dialog at all for ^C, etc. And if we handle these meaningful exceptions properly, I doubt we want to show anything more in the default dialog. Users don't need to know if the exception was a page fault or an illegal instruction. We can of course have a show details button that shows the whole backtrace info. I have also concerns about the message box that is displayed inside start_debugger() if the debugger is not to be started automatically - is it safe to assume the process is still capable to run the message loop for the window? No, of course it doesn't always work, but even simply starting the debugger cannot always work either, there's nothing we can do about that. -- Alexandre Julliard julli...@winehq.org
Re: Sound problems with latest kernel -- formerly a pulseaudio thread but not any more
Susan Cragin wrote: I have tested the following and I believe found they were not the problem: --snip-- (3) problem with pulseaudio How did you determine this? I thought you said your version of Ubuntu was crippled if pulseaudio was removed, so did you use pasuspender? If so, did you verify there was no pulseaudio process running while you were testing Wine? After I started my testing, I did run into problems when I tried to re-install pulseaudio and then remove it, but the PA problem was unrelated. Ubuntu said there was a PA bug, and issued a fix. After I applied the fix, no more problems working with pulseaudio removed. So the whole thing was sort of a red herring. I have re-installed my entire system since that problem went away, and immediately purged pulseaudio, and that's where I'm working from now. Still same problem. OK, thanks for that clarification. So you've tracked the problem down to kernel version 2.6.29? What version of ALSA drivers are in your working and broken kernels? I've actually tracked it to before that. Wine's audio last worked with one of Ubuntu's generic kernels, probably 2.6.28-10. Ubuntu's current repository kernel is 2.6.28-11. That's the one I that caused the problem. The experimental bug-fix kernel is 2.6.28-12. That does not solve my problem. (Here's where I got the kernel: http://kernel.ubuntu.com/~dtchen/test-kernels/ ) When my kernel worked, my drivers were 0.1.19 -- one of Tashaki Iwai's daily stable builds from a couple of weeks ago. They are 0.1.19 now, today's daily stable build, compiled against 2.6.29-1-rt8-custom, which is what I am running at the moment. My 29-rt kernel is showing the same problems as the two kernels mentioned above. FWIW, the person who compiled the RT kernel said that he did so without applying the Ubuntu patches. So that tells me that the change took place outside the Ubuntu patches. I've had a few users report crashing in steam games as a result of pulseaudio: https://bugs.launchpad.net/bugs/367379 -- do you think this is all related? Thanks, Scott Ritchie
Fw: Re: Sound problems with latest kernel -- formerly a pulseaudio thread but not any more
Whoops. This should have gone to the list. Susan Cragin wrote: I have tested the following and I believe found they were not the problem: --snip-- (3) problem with pulseaudio How did you determine this? I thought you said your version of Ubuntu was crippled if pulseaudio was removed, so did you use pasuspender? If so, did you verify there was no pulseaudio process running while you were testing Wine? After I started my testing, I did run into problems when I tried to re-install pulseaudio and then remove it, but the PA problem was unrelated. Ubuntu said there was a PA bug, and issued a fix. After I applied the fix, no more problems working with pulseaudio removed. So the whole thing was sort of a red herring. I have re-installed my entire system since that problem went away, and immediately purged pulseaudio, and that's where I'm working from now. Still same problem. OK, thanks for that clarification. So you've tracked the problem down to kernel version 2.6.29? What version of ALSA drivers are in your working and broken kernels? I've actually tracked it to before that. Wine's audio last worked with one of Ubuntu's generic kernels, probably 2.6.28-10. Ubuntu's current repository kernel is 2.6.28-11. That's the one I that caused the problem. The experimental bug-fix kernel is 2.6.28-12. That does not solve my problem. (Here's where I got the kernel: http://kernel.ubuntu.com/~dtchen/test-kernels/ ) When my kernel worked, my drivers were 0.1.19 -- one of Tashaki Iwai's daily stable builds from a couple of weeks ago. They are 0.1.19 now, today's daily stable build, compiled against 2.6.29-1-rt8-custom, which is what I am running at the moment. My 29-rt kernel is showing the same problems as the two kernels mentioned above. FWIW, the person who compiled the RT kernel said that he did so without applying the Ubuntu patches. So that tells me that the change took place outside the Ubuntu patches. I've had a few users report crashing in steam games as a result of pulseaudio: https://bugs.launchpad.net/bugs/367379 -- do you think this is all related? Thanks, Scott Ritchie Maybe. From the bug, it's hard to tell. But here's what I think. I think that the kernel made changes recently that changed how sound relates to the kernel, and tied pulseaudio closer to the kernel (hence those error messages I got under 2.6.28-11, which kernel was acknowledged to be buggy the day it came out). Some of the bugs they either backed out or corrected with 2.6.28-12. It would be interesting to see if they can get steam running with that kernel. If you are working with the steam-bug people ask them to add the below kernel, purge pulseaudio, and test with alsa only. http://kernel.ubuntu.com/~dtchen/test-kernels/ Of course, they need headers, image restricted modules. Susan
