[Gwc-general] gwc-0.20.08 -- hangs after playback

[Atwood, R. C <r.a...@im...>]

gwc certainly looks like it will serve the purpose of removing one more =
reason to run Windows on the machine! However, I experienced one =
significant problem already -- the program hangs when it reaches the end =
of a selected region upon play back.

I debugged it, which led me to the following subroutine at =
audio_util.c:901


______________________________________
void stop_playback(int force)
{
    if(!force) {
	while(audio_device_processed_bytes() < playback_total_bytes) {
	    //g_print("usleep 100\n") ;
	    usleep(250) ;
	}
	usleep(100) ;
    }
    audio_state =3D NOTHING ;
    audio_device_close() ;
}
________________________________________

For some reason, the number returned by audio_device_processed_bytes() =
remains less than playback_total_bytes. At the same time, and for =
reasons that my lack of gui-interface programming prevents me from =
understanding, the toolbar buttons are not active at this point.

It seems like something to do with the playback transferring a fixed =
parcel of data which is larger than the selction resolution, so it stops =
transferring while some selected bytes remain, is this possible?  I am =
willing to look into this further but I though  someone here might =
already understand the problem and see right away what is happening.


My quick fix is to test whether the result of =
audio_device_processed_bytes() has changed during the usleep and break =
if it has not. This works for me! So far it has not exited the playback =
at an incorrect time due to this change.=20


The system is: Slackware 10.0 with rebuilt 2.4.26 kernel, alsa with oss =
emulation (compiled so that only EMU10k1 and dummy modules are built), =
SB-Live! soundcard, cheep motherboard with a 'via 1-giga-pro' processor =
(possibly via-c3 ???)=20

Also I noticed that ./configure selected -mcpu=3Di686 -march=3Di686 for =
my system but actually this doesn't work. I guess that is because the =
cheap processor claims to be more than it is! I found that the 2.4.26 =
kernel configured with i686 did not work either. Could the ./configure =
check what the kernel is actually configured for instead of what the =
processor claims to be (as ALSA does?) Just a thought ... it is easy =
enough to fix the Makefile, only, less geeky people than I might be put =
off if the autoconfigured program doesn't work and the reason is not =
obvious ("illegal instruction") But I have no idea how many processors =
might exhibit this behaviour :-()

Robert
r.atwood at imperial dott ac dott uk



=20