Hello Jerry,
Saturday, October 4, 2003, 11:56:11 AM, you wrote:
JJ Only one of my sound cards suffers from the problem when the format of
JJ primary buffer is 22050 samples per second, 8-bit stereo.
What's the soundcard ?
--
Best regards,
Olegmailto:[EMAIL
Here is the patch that addresses the 8 bit mixer problem. I just
cut it out of an old development tree that had a lot of other mixer
changes so I doubt it will apply cleanly but it will give you an idea
of the problem.
This patch and the tests developed for it uncovered the locking
issues which
Robert Reif wrote:
Here is the patch that addresses the 8 bit mixer problem. I just
cut it out of an old development tree that had a lot of other mixer
changes so I doubt it will apply cleanly but it will give you an idea
of the problem.
This patch and the tests developed for it uncovered
Robert Reif wrote:
Here is the patch that addresses the 8 bit mixer problem. I just
cut it out of an old development tree that had a lot of other mixer
changes so I doubt it will apply cleanly but it will give you an idea
of the problem.
This patch and the tests developed for it
sox -c1 -r44100 -sw /usr/share/sounds/pop.wav -tossdsp /dev/audio
wine winamp
has the problem, but
sox -c1 -r44100 -sb /usr/share/sounds/pop.wav -tossdsp /dev/audio
wine winamp
is unbelievably good. How could it be? I should find out if it's
something is wrong with my system or something else.
Dimitrie O. Paun wrote:
The best thing to do is to post it here so we can see what we are
talking about... And yes, we all want only the best code for wine :)
The code is already submitted in my patch. After thinking twice, I found
that the runtime check can be sped up. Calling
Dimitrie O. Paun wrote:
That's still a compile-time check. A runtime check runs when wine runs...
But the test is really a time-cost task. I won't merge it into WINEALSA if I
can't improve it.
Does anyone have any suggestions?
--
Dimi.
On Tue, 2003-09-30 at 07:43, Jerry Jenkins wrote:
But the test is really a time-cost task. I won't merge it into WINEALSA if I
can't improve it.
Does anyone have any suggestions?
Well I for one am a bit confused. The reason it needs to be a runtime
check is so we can compile Wine on one
Well I for one am a bit confused. The reason it needs to be a runtime
check is so we can compile Wine on one machine then run it on a totally
different one, and Wine figures out what it can and cannot do on the
fly. If we are altering its behaviour according to the capabilities of
the
On Wed, 1 Oct 2003, Jerry Jenkins wrote:
I knew. I also want it can be compiled once and run on any other machines.
My point is that only the best code should go into the wine, and the test
code I have written is not so¡ :-(. It will give someone many troubles if
he wants to do something
Hi Jerry,
With your patch applied,
I get a write access to a NULL pointer when trying to get sound with
dsound (winmm tests are running ok.)
Since I was using precompiled RPMs from freshrpms.net when doing the
first try,
I switched to 0.9.7 sources. Same result.
I attached a trace from a run of
With the trace its better ;)
I attached a trace from a run of
wine dsound_test.exe.so dsound --debugmsg +wave,+dsound,+dsound3d
=
Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net)
ICQ #170597259
Say NO to software patents
Dites NON aux brevets logiciels
What if tomorrow the
Hi Jerry,
With your patch applied,
I get a write access to a NULL pointer when trying to get sound with
dsound (winmm tests are running ok.)
Since I was using precompiled RPMs from freshrpms.net when doing the
first try,
I switched to 0.9.7 sources. Same result.
I attached a trace from
If the behavior is subject to change, there is no way you can test
that at configure time. This needs to be a run time check.
You're right. So I put some code in configure.ac, try to compile run it
when configure is executed. If everything is OK, a macro will be defined in
config.h.
On Tue, 30 Sep 2003, Jerry Jenkins wrote:
You're right. So I put some code in configure.ac, try to compile run it
when configure is executed. If everything is OK, a macro will be defined in
config.h.
That's still a compile-time check. A runtime check runs when wine runs...
--
Dimi.
Jerry Jenkins [EMAIL PROTECTED] writes:
Based on this thought, I need a function to retrieve the buffer. Then
I found that snd_pcm_mmap_begin is the right one. But no documents
said that it is responsible for return the driver's buffer. Well, I
can verify that, and the result is really
16 matches
Mail list logo
