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

[Jeff W. <we...@ya...>]

Thanks for the bug report.

I also caught the hanging problem and have a fix when 0.20-09 is 
released.  What I wanted to achieve with
that little loop not closing the audio device prematurely, which I think 
is one source of a small clicking sound
at the end of playback.  I think, though, I haven't got the problem 
licked, because even though the audio
device has receieve all the bytes in it's internal buffer, it hasn't 
played them all.

0.20-09 will also have a fix for snapping to markers when the markers 
are close to each other,
as well as a lowpass iir filter, and amplify can now mix/crossfade from 
the left/right channels.

jw

Atwood, Robert C wrote:

> 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 = 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.
>
>
> 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 ???)
>
> Also I noticed that ./configure selected -mcpu=i686 -march=i686 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> !DSPAM:41ded56f45821239941626!