(Optical) drive not found

I’m currently working on a simple application that allows the user to do a
statistical analysis of the audio sample values in a chosen ‘track’ when
there is an Audio CD in the optical drive. Plan to release this soon so
people can learn the (sometimes depressing) truth about the technical
quality of recordings on CD.

The application works on my ARMiniX, but has thrown up an occasional
problem I also encountered with my Iyonix. This is that when booted up the
machine sometimes seems not to know the optical drive is present. So when
the application does a scan to find the optical drive I get a ‘Drive not
found’ error.

Clicking on the drive iconbar icon also gives an error. FWIW The system is configured to have one optical drive which then is given cdfs number ‘0’.

With my Iyonix a cure (for some unknown-to-me reason) was to have a disc in
the optical drive when the machine was powered up. If I did that, the drive
was always found. Omit it, and the drive never was found.

I suspect this is a long-standing bug in the OS that sometimes manifests.
So I’m raising it to see if others encounter the problem in case I can get
the application to do something that deals with it. Is there a “Look, I
know there IS a drive, so find it!” command? 8-]

Yes, my program is scanning the relevant range of values to find the hardware that the OS should say is linked to cdfs ‘0’.

This morning I had the problem, did a switch-off-and-on-again with a disc
in the drive, and still ‘not found’. Did it again and – ta-daa! – the drive
was present. No idea why it works some times and not others. The disc whirs
regardless when there’s a disc present. And when the drive is found my program can tell if a disc is present or not, OK. So the problem seems to be an inconsistent failure for cdfs ‘0’ to be connected to the drive by the OS at bootup.

Jim

Does the drive, when not recognized by CDFS, show up on the SCSI bus? Just to narrow down the culprit.

For the Iyonix (assuming this is an internal drive) they shouldn’t show up on the SCSI bus at all – the ATAPI module communicates directly with CDFS.

Not sure offhand if there’s a *command to list IDE/ATAPI devices.

*CDFS
*CDDEVICES

Or you can also enter it as:
*CDFS:CDDEVICES

I dont know if this is the same thing, but I am looking for a way to check if there is a USB audio device plugged in.
Redirecting the output of *USBDevices to a temp file that can have a simple grep of ‘audio’ done is what I have thought of. Possibly a small BASIC program that steps through the buffer for ’a’+’u’+’d’+’i’+’o’ would be OK.
But if I am in BASIC maybe I can more directly get a message from a SWI?
Couldn’t see anything in the stronghelp anywhere though.
Edit: I found something under Service Calls→USBdriver, looks like I need the SWI for Service call with R1=&D2 and R0=1 (connected)
SYS"Service_USBDriver",1,&D2,buf%
where buf% is the pointer to the USBServiceCall blocks, but with a possibility of +n descriptors how do I know what size to allocate to buf%?
Or is R2 just a copy of an already existing buffer start address?
“Pointer to linked list” sort of implies it is already made.
Then the requirement
“It is the responsibility of the issuer of the call to free the memory used by the returned descriptors in the RMA” ???

I am looking for a way to check if there is a USB audio device plugged in.

My USBAudio module provides what you need. Visit my web site and go to the Audio section. There is full documentation of the API.

My USBAudio module provides what you need.

Yes I looked the other day. Probably further ahead than I am prepared to work at the moment, but can they be part of the GCC Oslib for linking as well?

I am playing with a (quirky) Obey/Taskwindow setup that will decode flacs through
PipeFS to Colins !RunImage at the moment.
I cant duplicate the success with mpg123 or aac-dec for some reason.
Success is a bit strong, I think the pipe: is using a bit more cpu than it should for the job. I did some timings one time and it appeared to be copying byte at a time, I think it causes a bottleneck.

mpg123 compiled with fixed point is very fast at decoding, and could just buffer whole mp3’s through ram without much trouble.

can they be part of the GCC Oslib for linking as well?

Not sure what you mean by that. I’m hoping that my module will be part of the next release of RO, although I had hoped that would have happened before the South West Show. I submitted the source to ROOL months ago.

As for the rest: I really would recommend that you go the whole hog and use USBAudio, which will open a DeviceFS stream for you. You should be able to ship the output of a decoder to the stream.

Note that you will still need Colin’s USB modules, as they also have not made it into RO yet.

Well, on the one occasion I have used RISC OS filer SWI’s from !GCC it was because of the !GCC OSLib addition, I’m not sure wether your swi’s have to be written into OSLib to use them or not. Generally !GCC can do what DDE can do, Maybe someone will update OSLib if there are significant changes to RISC OS.

Does the drive, when not recognized by CDFS, show up on the SCSI bus? Just to narrow down the culprit.

There are a number of tests/checks like that I’m now planning to try. However, most of the time the drive works OK, so I’m awaiting a chance…

Jim

I’m not sure wether your swi’s have to be written into OSLib to use them or not.

Ah, you just mean the hash defines? You don’t need them, you can put equivalent hash defines into your code and call the SWIs. I’m not within range of a RO system right now so I can’t give every last detail, but, since you can write C, clearly you can find what you need.

clearly you can find what you need.

That maybe the case with your API.
After looking at the size of the flac source code, It looks like a lengthy undertaking. The fdk-aac decoder comes with an api, but I’ve read that the flac binary lends itself to streaming better than the rest and it’s probably the best one to kick off with.
I have put up the current flac2usb player

Well, on the one occasion I have used RISC OS filer SWI’s from !GCC it was because of the !GCC OSLib addition, I’m not sure wether your swi’s have to be written into OSLib to use them or not. Generally !GCC can do what DDE can do, Maybe someone will update OSLib if there are significant changes to RISC OS.

This doesn’t really make sense.

OSLib is nothing to do with GCC: it’s a completely separate API library for RISC OS that can be used just as well with Norcroft as with GCC. “Natively”, GCC uses exactly the same methods of accessing SWIs (via kernel.h and swis.h) as Norcroft. Just as with Norcroft, using OSLib is a far preferable thing to do because it makes code cleaner…

And yes, as far as I know the OSLib maintainers are more than happy to receive updates as the OS and third-party modules evolve. The OSLib mailing list is the place to ask.