Initial experiments show that we can get some noises out of a pulse audio daemon on a PI BUT after a while it will manage to look-up the Scratch process due to a problem with the thread handling.
The error message is
DBG: sqUnixSoundMaemo: >sound_Stop() (11, Resource temporarily unavailable)
which is generated when using a debug enabled copy of vm-sound-pulse/SqUnixSoundPulseAudio.c at line 903. The odd thing here is that this is entering the routine which must surely mean that 'errno' must have been set previously?
Just for the record, when starting up with -vm-sound-pulse, the initial stop requested by the image startup/resume code triggers an error that does not lock up the system (obviously!)
DBG: sqUnixSoundMaemo: >sound_Stop() (2, No such file or directory).
The only prior DBG output at that point is
writerThread: started <-- ll 538
writeThread: waiting <-- ll 543
readerThread: started <-- ll 608
readerThread: waiting <-- ll 613
While running ok we get some
writerThread: running
and
writerThread: waiting
pairs.
Given past experience with ALSA and their idiotically broken library, there has to be a chance that this code also messes badly with interrupts.
Initial experiments show that we can get some noises out of a pulse audio daemon on a PI BUT after a while it will manage to look-up the Scratch process due to a problem with the thread handling. The error message is DBG: sqUnixSoundMaemo: >sound_Stop() (11, Resource temporarily unavailable) which is generated when using a debug enabled copy of vm-sound-pulse/SqUnixSoundPulseAudio.c at line 903. The odd thing here is that this is entering the routine which must surely mean that 'errno' must have been set previously?
Just for the record, when starting up with -vm-sound-pulse, the initial stop requested by the image startup/resume code triggers an error that does not lock up the system (obviously!) DBG: sqUnixSoundMaemo: >sound_Stop() (2, No such file or directory). The only prior DBG output at that point is writerThread: started <-- ll 538 writeThread: waiting <-- ll 543 readerThread: started <-- ll 608 readerThread: waiting <-- ll 613
While running ok we get some writerThread: running and writerThread: waiting pairs.
Given past experience with ALSA and their idiotically broken library, there has to be a chance that this code also messes badly with interrupts.