Thread-Safe CD-Rom Access????

[PH3NOM]

Whats up guys? I hope all is well!

I am still working on Dreamcast Media Center.

I have came across a problem, that I am struggling to work out.

The AVI (XviD) decoder is currently using 2 threads.
One thread is the video decoder, the other thread is the audio decoder.

Both of these threads need to read the AVI file from the /CD/.
Serious problems occur when both threads attempt to read from the /CD/ at the same time.

I have tried a few blocking methods to prevent simultaneous reads:
- Using a mutex
- Using a volatile int and thd_pass()

Using a Mutex to lock the AVI audio/video reads works great when streaming an avi file from /romdisk/
But, when streaming an AVI file from /cd/, the application will quickly crash.

I even tried a third thread that does nothing other than read from the /CD/ into respective buffers.
This created even more problems

I am running out of ideas, any help is appreciated!

[BlueCrab]

As long as you're using separate handles to the file, it should "just work", as far as I can tell. Both the ISO9660 layer and the raw CD-ROM sector reading code have what appears to be appropriate mutexes and such to prevent concurrency problems.

Now, if you're using the same FILE * from two threads and seeking around in it, that could cause all kinds of problems. That is a very bad idea in general.

Granted, I haven't explicitly tried this myself, but it looks like it should work just fine (at least to me at 2AM when I'm looking at it).

[Quzar]

I've been in and out of the CD-ROM driver, and from that level there should be no problem (there is no point where the hardware will receive two simultaneous requests or such). I can imagine though that further up into the FS layers there is a problem.

Most threading stuff is greatly untested on the DC as, even when used, it has only really been used in small quantities in specific circumstances.

[OneThirty8]

I'd copy the data you want from the CD into RAM and then let the audio and video threads handle it from there. I believe that's what DCDivX did, and that's what I did with VC/DC. One thing that I was going to try with VC/DC that I don't think I ever got around to was reading ahead in a separate thread to keep my buffer as full as possible at all times. You might need to rework some of your code or figure out how to handle seeking this way, but I think it's generally easier to deal with it this way. Also, I don't think I used separate threads for decoding, but I did use separate threads to handle a/v sync and copy data to the sound hardware whenever it needed more data, and to to copy the decoded video frames to the PVR and display it at the right time.

[PH3NOM]

Thanks for all the input guys!

Yesterday, I double checked everything.
I have a separate FILE* handle for the audio and video processes, initialized in each respective thread.

Its the sort of thing I thought should be handled at the kernel level. I am still not sure where the exact problem is occurring.
Considering everything works perfectly when streaming from /romdisk/, this indicates the problem is directly related to the /cd-rom/, maybe seek speed just isn't fast enough?

Regarding K:OS threading, I am using an older version of K:OS, should I update to the newest build?
I remember BluCrab mentioning some work he had done with K:OS threading...
I could look at merging the 2 threads into a single thread, but I think this would slow things way down.

Good to see you around by the way OneThirty8.
Your response confirms my fears.
It will be necessary to load the avi file into /ram/ and parse it from there.
But, what is the best approach?
I considered fs_read() say 4mb of the file from the /cd/ into /ram/ at a time, double-buffered, and operating on the file segments in ram.
But a quick attempt revealed that the AVI file parser must operate on the entire file, so that didnt work.

[OneThirty8]

I would look at how DCDivX handles parsing the AVI file, because it uses a fairly large buffer. I'm sure the source code is still available. It had some sort of a buffering system that seemed to work pretty well.

[BlueCrab]

Regarding K:OS threading, I am using an older version of K:OS, should I update to the newest build?
I remember BluCrab mentioning some work he had done with K:OS threading...

It might help, but I can't really say for sure. The only issue with updating to a new version of KOS is that you're likely going to have to rebuild a large part of your toolchain to do so, especially if you use C++ at all (you probably only have to rebuild newlib if you're only using C).