Hi Rocky, Thanks for the explanation. I don't think I can even set up the cabling you explained as I'm using a laptop drive attached using a USB adaptor. It's the only working drive I could find!
That said, I was expecting 'cdda-player -s' to stop the drive when it was already playing. The ioctl seems the succeed, but something must be making it play again. I'll look into it. Maybe I shouldn't worry. Is there a utility I can use to test all of the modern usages of cd drives? As for memory leaks, I've must admit I've not checked yet, but I will give it a shot soonish. Thanks! On 19 June 2018 22:46:37 BST, Rocky Bernstein <[email protected]> wrote: >I looked over the patches so far and all looks good. Thanks. > >cdda-player is weird in that it uses a CD-ROM in a way that isn't >normally >done much nowadays: there is a command to the cd-rom to start playing >in >some sort of audio mode and through a jack on the drive you listen. So >other than commands going from the computer to the drive and status >coming >back in response to a command, the CD-ROM is working independently of >the >computer. What's more prevalent nowadays is that the audio data gets >sent >back to the compuer as WAV data and the computer uses that through it's >sound processing system. > >In order to make this work, some cables on the CD-ROM might need to be >hooked up that aren't otherwise used. > >I just tried the current cdda-player on an Ubuntu system and I'm not >getting status back which probably means I don't have the right cables >hooked up for that. I did issue a "cdda-player -s" and it came back >without >any error messages. But then it may or may not have done anything. > >In sum cdda-player maybe something that is of little interest nowadays. > >Have you tried looking for memory leaks? Were there any? > > > >On Tue, Jun 19, 2018 at 5:24 PM, Edd Barrett <[email protected]> >wrote: > >> Hi all, >> >> A quick status update on the OpenBSD work. >> >> On Mon, May 28, 2018 at 11:45:07AM +0100, Edd Barrett wrote: >> > On Sun, May 27, 2018 at 02:22:48PM +0200, Robert Kausch wrote: >> > > RAW_PART is always 2, thus 'c', in OpenBSD, but it's architecture >> dependent, >> > > 2 or 3, in NetBSD [1]. So it would be a good idea to use RAW_PART >> instead of >> > > a fixed 'c' or 'd' when looking for devices. >> >> I had some time to work on libcdio tonight. I've made a git fork with >a >> branch off of your 2.0.0 tag (that's the version I'm targeting for >now): >> https://github.com/vext01/libcdio/commits/openbsd-porting >> >> I'm having issues with cdda-player sadly, which suggests my work here >is >> not yet done. Can someone on Linux confirm if `cdda-player -s` works >(to >> stop playback). >> >> I'm also seeing a whole load of this in the dmesg buffer: >> Jun 19 22:15:43 arrakis /bsd: cd1(umass0:1:0): Check Condition (error >> 0x70) on opcode 0x1a >> Jun 19 22:15:43 arrakis /bsd: SENSE KEY: Illegal Request >> Jun 19 22:15:43 arrakis /bsd: ASC/ASCQ: Invalid Command >Operation Code >> >> I've not yet had time to look into that one. >> >> Thanks. >> >> -- >> Best Regards >> Edd Barrett >> >> http://www.theunixzoo.co.uk >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
