Bugzilla – Bug 9463
SC does not kill faad.exe when skipping tracks
Last modified: 2010-07-21 20:04:36 UTC
[pasted from support ticket# 080908-002127 -DE] On a small embedded Lunix system I have SC 7.1 running fine. In order to listen to AAC files (*.m4a and *.mp4) I used accompanied by the relevant custom-convert.conf files. For some reason mplayer creates clicks on every track change so I switched to faad (and changed the custom-convert.conf) Faad works OK, no clicks. There is one problem. When a track is skipped a new faad exe is started up by SC. The old faad exe should now be terminaded. However the old exe keeps running, seemingly until the original song is completely decoded. This is trouble, as for example 4 skip's means 4 + 1 running exe's and no time to decode without stuttering. Question: HOW exactly does SC terminate end a convertor exe which is not needed anymore? Is is signalled, and if so by which signal? (I assume faad is not listening to a signal and I would like to know to which signal faad should listen in order to patch faad.) [addendum from customer -DE] FYI: in these old post the same problem is reported: * http://forums.slimdevices.com/showthread.php?t=27190 * http://forums.slimdevices.com/showthread.php?t=8998 In the mean time I checked if the faad process in my situation listens to a SIGPIPE signal by runnubng faad in the commandline and using 'kill -s PIPE'. This works as expected. Faad quits as it should when a SIGPIPE is send. Of course it could be that SIGPIPE is not used by SC, therefore my question remains: HOW exactly does SC terminate a convertor exe which is not needed anymore? Is is signalled, and if so by which signal?
I sent the faad author a patch a long time ago to terminate if it could no longer write to the output - it didn't seem to get included though. In terms of transcoding killing the process, I played with this for alien and was not convinced it worked in all cases - if we only create a single process then it is ok, if we span pipe then this runs under a shell and you can end up killing the shell and not the individual processes. (maybe I didn't try hard enough though - this is the reason for the kludgy mplayer.sh script with alien)
James could you add a note about this bug to our FAAD wiki page?
Updated the following WIKI page with information about FAAD: http://wiki.slimdevices.com/index.php/AAC Also updated the included Forum posts to point to this bug and WIKI page
As poster of the original support ticket I would like to comment: * The updated wiki page states: "Note: There is a known bug in FAAD that may cause some tracks to be skipped. See bug 9463, as well as the associated forum post for more information." This is not correct. A better summary would be: "Note: There is a known bug that may cause hanging FAAD processes when tracks are skipped. Hanging FAAD processes may lead to stuttering/no sound and/or to an less or unresponsive system. See bug 9463, as well as the associated forum post for more information."
(In reply to comment #4) > As poster of the original support ticket I would like to comment: > * The updated wiki page states: > > "Note: There is a known bug in FAAD that may cause some tracks to be skipped. > See bug 9463, as well as the associated forum post for more information." > > This is not correct. A better summary would be: > > "Note: There is a known bug that may cause hanging FAAD processes when tracks > are skipped. Hanging FAAD processes may lead to stuttering/no sound and/or to > an less or unresponsive system. See bug 9463, as well as the associated forum > post for more information." > Thank you for the correction. I have updated the WIKI page with your suggested text. Feel free to modify it or leave additional comments here or on the wiki/forum.
Moving monitor bugs
Triode: Can you post your patch for faad?
Fixed in change 24580.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
I've run into this bug using Squeezebox Server 7.5.1 / r30836 on a PowerPC Macintosh running OS X 10.5.8 being used with a Squeezebox 2. If I skip an AAC track this currently playing, the faad process is not closed and has to be killed manually.