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...
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 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 compiling machine then this is very bad indeed.
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 compiling machine then this is very bad indeed.
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 about the performance.
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 about the performance.
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 :)
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 snd_async_callback_t twice is enough. Because we could commit the whole buffer for the first time, ALSA driver will know the buffer is full. If the buffer will be reallocated, it is the right time for the driver to perform the action. And the new address will be returned next time we call snd_pcm_mmap_begin. We need not wait for the whole buffer to be played once.
And I got some new information about the noticeable interval. Seems it's something about the sound data format was not correctly set, for
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.
--
Dimi.
-
Dimitrie O. Paun -
Jerry Jenkins -
Mike Hearn