Menu
▾
▴
Re: Alsa problems (Was: Re: [Gwc-general] GWC 0.21-03 is released)
|
From: Jeff W. <we...@ya...> - 2005-11-15 00:08:04
|
That is good news Johan. Thanks for being willing to test this out.
Now it looks like the problem is the buffer size GWC is using for ALSA
is too small (512 bytes), which is probably the reason for the remaining
errors.
I'll tackle that next.
Cheers,
Jeff
Johan De Groote wrote:
>Hello Jeff,
>
>Took a bit longer as expected, but we had a long weekend so I hardly saw the
>pc.
>
>Started wih a clean copy of the code, then replaced the alsa.c by the one you
>send and spliced in the makefile.fix in makefile.in. Used "./configure
>--enable-alsa" like the previous time.
>
>Issueing "make" still gives the old problem of "x86-64" not being recognised.
>But once I change that to "k8" in the Makefile it compiles cleanly.
>
>The change is enormous! Playback doesn't stop anymore, it plays the whole
>selection. There are still errors, but they do not always give an audible
>"disturbance". Sometimes you get a slight click but nothing more than you
>would expect from an LP recording (and much less than on some LPs). I have
>not yet tried to check if the click comes with the underrun or the other
>message.
>
>I played a 20 second selection, and below is the output to the terminal.
>
>Thanks,
>Johan
>
>[Terminal output]
>daw gwc-0.21-03 # gwc
>Current stack limit: 8388608 bytes
>ALSA audio_device_best_buffer_size:512 (frames:128)
>##########################################################
>audio_device_processed_bytes: ALSA buffer underrun
>Broken pipe
>##########################################################
>audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update
>Broken pipe
>##########################################################
>audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update
>Broken pipe
>##########################################################
>audio_device_processed_bytes: ALSA buffer underrun
>Broken pipe
>##########################################################
>audio_device_processed_bytes: ALSA buffer underrun
>Broken pipe
>##########################################################
>audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update
>Broken pipe
>##########################################################
>audio_device_processed_bytes: ALSA buffer underrun
>Broken pipe
>##########################################################
>audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update
>Broken pipe
>##########################################################
>audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update
>Broken pipe
>##########################################################
>audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update
>Broken pipe
>##########################################################
>audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update
>Broken pipe
>##########################################################
>audio_device_processed_bytes: ALSA buffer underrun
>Broken pipe
>
>Stop playback with playback_samples_remaining:0
>##########################################################
>audio_device_processed_bytes: ALSA buffer underrun
>Broken pipe
>Closing the ALSA audio device
>[end terminal output]
>
>On Saturday 12 November 2005 15:49, you wrote:
>
>
>>Hi James,
>>
>>Good to hear from you!
>>
>>I've been reading a little on ALSA this pase week, and it looks like not
>>handling
>>the EPIPE error is behind some of GWC's troubles. I was showing the
>>"broken pipe"
>>errors consistently at the end of a playback section -- because the playback
>>cursor lags a few milliseconds behind the audio playback, and the call to
>>snd_pcm_delay in function audio_device_processed_bytes would give the
>>EPIPE when the audio_buffer had already emptied. This does not affect
>>playback
>>sound quality, but I have trapped that error.
>>
>>I took your thought here about the EPIPE in the
>>nonblocking_write_buffersize call
>>and added one tweak -- attempt recover the sound device handle before
>>failing.
>>
>>Attached is my current audio_alsa.c (which changed the function perr to
>>snd_perr,
>>and recover_write to recover_snd_handle.) See how this works. Johan,
>>let us know.
>>I think there is still problems with the audio buffer size, and when
>>playback starts
>>there will be a message on the console, if you could tell us what it says:
>>
>> "ALSA audio_device_best_buffer_size:xxxx (frames:xxxx)"
>>
>>---
>>For the Makefile problem, if you will insert the lines from Makefile.fix
>>indicated below,
>>it will pick up changes to the audio src. You can put these lines into
>>Makefile.in as well
>>and then "configure" will build the right Makefile. I'd just send my
>>Makefile but I don't
>>know what other options you may or may not have. Be sure for the
>>indents that it is a single
>>tab, or make won't work properly.
>>
>>############### Changes for Makefile ####################################
>>
>>gwc : $(OBJS) meschach.a
>> $(CC) $(OBJS) $(EFENCE) $(LFLAGS) $(LIBS) -o gwc
>>==>
>>==> audio_device.o : audio_device.c audio_alsa.c audio_oss.c audio_osx.c
>>==> $(COMPILE) -c audio_device.c
>>
>>.c.o :
>> $(COMPILE) -c $<
>>
>>#####################################################################
>>
>>Cheers,
>>Jeff
>>
>>James Tappin wrote:
>>
>>
>>
>>>On Wednesday 02 November 2005 21:51, Johan De Groote wrote:
>>>JD> I can open it fine, load a file, make a selection etc. But if I hit
>>>playback I JD> get:
>>>JD>
>>>JD> ...
>>>JD> ##########################################################
>>>JD> audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update
>>>JD> Broken pipe
>>>JD> audio_device_processed_bytes: snd_pcm_delay Broken pipe
>>>JD> ##########################################################
>>>JD> audio_device_nonblocking_write_buffer_size: snd_pcm_avail_update
>>>JD> Broken pipe
>>>JD> audio_device_processed_bytes: snd_pcm_delay Broken pipe
>>>JD> ...
>>>JD>
>>>JD> Once this message starts sound stops and so does the cursor. Until I
>>>
>>>
>stop
>
>
>>>JD> playback this message keeps coming in the terminal. The time to get
>>>
>>>
>this
>
>
>>>is JD> variable, but never longer than a few seconds (15 at most). Gwc
>>>doesn't JD> crash, and alsa continues as well. Hitting playback again will
>>>restart the JD> selection, until "it" happens again.
>>>JD>
>>>
>>>Hi, I'm back!
>>>
>>>I think I'm making some progress on this one (which seems to be a similar
>>>problem to one I was having a while back (April 04) [only then it wasn't
>>>possible to stop it]. snd_pcm_avail_update() returns -EPIPE if the output
>>>buffer has emptied, and the driver has tried to get some data. Because
>>>audio_device_nonblocking_write_buffer_size() bails out on any error, the
>>>buffer never gets filled so it goes into an infinite loop. I think that the
>>>answer is at least in part to modify audio_alsa.c, so that a "broken pipe
>>>error is effectively ignored (patch at the end) -- it could be rearranged
>>>
>>>
>to
>
>
>>>eliminate the message altogether but I was trying to see what influenced
>>>
>>>
>the
>
>
>>>problem.
>>>
>>>The other things that may help are to increase the buffer size (in
>>>audio_device.h) [BTW there is a redundant redefinition of MAXBUFSIZE in
>>>audio_util.c which ought to be removed.] and not popping windows or
>>>
>>>
>generally
>
>
>>>doing too much with X while playing back.
>>>
>>>James
>>>
>>>P.S. I've changed distro yet again -- Kubuntu now.
>>>
>>>++ BEGIN PATCH ++
>>>*** audio_alsa.c 2005-11-11 16:28:08.000000000 +0000
>>>--- audio_alsa.c~ 2005-11-11 15:57:50.000000000 +0000
>>>***************
>>>*** 267,273 ****
>>> if (frames < 0) {
>>> perr("audio_device_nonblocking_write_buffer_size:
>>>snd_pcm_avail_update",
>>> frames);
>>>! if (frames != -EPIPE ) return 0;
>>> }
>>> len = snd_pcm_frames_to_bytes(handle, frames);
>>>
>>>--- 267,273 ----
>>> if (frames < 0) {
>>> perr("audio_device_nonblocking_write_buffer_size:
>>>snd_pcm_avail_update",
>>> frames);
>>>! return 0;
>>> }
>>> len = snd_pcm_frames_to_bytes(handle, frames);
>>>++END PATCH++
>>>
>>>
>>>As far as I can tell
>>>
>>>
>>>
>>>
>>
>>
>
>
>
|
