long:ALSA: Machine is too slow, calling snd_pcm_prepare()

[coderofsalvation]

ok, this is not highpriority, but only happens in the filebrowser when browsing a network-file folder (sftp directory with mp3's e.g.).
It seems to scan & display the file attributes (which takes longer over sftp) which blocks the audio-thread.

shortterm solution: copy the dir over to local disk

[mywave82]

Just scribling down for now:

OCP is single-threaded, and the internal file-API does not have multi-thread nor re-entrant in the design.

OCP used to have a timer-signal running to ensure audio was pushed through, but it did have some flaws due to it causing re-entrant usage of internal file-API when playing streamed formats like .ogg, .mp3, .flac and .wav + using file-browser at the same time. This could cause nasty things to happen.

Some external libraries does not handle possible EINTR on system-calls etc. well (have in the past caused problems to be fixed in ncurses, samba kernel filesystem driver, ...).

The long term goal should probably be to update the filesystem API to support multithreading, which is a safer approach than trying to make it re-entrant (and reintroducing SIGINT). And then add an audio-thread to keep the audio alive.