search

raspberrypi / scratch

Scratch releases
79 stars 21 forks source link

Attempting to record sound causes untrapped error #168

Closed timrowledge closed 8 years ago

timrowledge commented 8 years ago

(Oct15 release) Trying to open a sound recorder causes an untapped error; shouldn't do that. If we don't have the ability to record we need to fail gracefully. I think perhaps the nicest approach would be to let the UI open and display a clear(it) error message about the lack of sound recording capability.

timrowledge commented 8 years ago

There are two primary usages of SoundRecorder in Scratch code a) installing one in the recorder dialogue, with concomitant usage to actually record and return the final sample. When recording stops the thread calling the OS sound input is stopped. b) in the sensor blocks for 'loud?' and 'loudness' where a sound recorder is used to monitor the sound levels and provide the loudness value. These will start up (if needed) the sound recorder code and simple sample its 'meter level' as required. Unfortunately they will also result in the recorder loop running continuously thereafter, until and unless a recorder dialogue is used and finally stopped.

The system tries to keep a singleton SoundRecorder instance around, just as with the SoundPlayer. If needed it can create a new instance and hook it up correctly, suspending the low-level process except when needed.

Our problem is that the OS primitive to create and initialise the device driver(s) fails on linux when there is no connected hardware with a functioning driver - as on a raw Pi. The low-level code in the image is currently written with the assumption that the primitive call will not fail and thus when it does we get an unhandled error. Aside from the user confusion and annoyance this will cause in Scratch, the error arises in a place in code that is particularly infelicitous, so a solution would be nice.

timrowledge commented 8 years ago

After a lot of fiddling with ways to catch this error and do something clean with it I concluded that the simplest answer is to a) remove the primitiveFailed call from the primitive method initialising the recorder b) spot the failure by checking the actual sampling rate in use being 0 c) raise a simple Warning exception that the Scratch recorder morph can catch and handle.

The handler will open a simple Scratch warning dialogue to let the user know there is a known problem and then allow them to proceed. Aside from that warning, the recorder is quite happy to sit there and not do anything; I could find no crashes as a result.

timrowledge commented 8 years ago

Fixed in Scratch-tpr.298 and Sound-tpr-45 (required Squeak system code update)