From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EZ29b-00017r-1u for qemu-devel@nongnu.org; Mon, 07 Nov 2005 03:14:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EZ29W-00015E-Ow for qemu-devel@nongnu.org; Mon, 07 Nov 2005 03:14:57 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EZ29U-000147-S9 for qemu-devel@nongnu.org; Mon, 07 Nov 2005 03:14:53 -0500 Received: from [195.184.98.160] (helo=virtualhost.dk) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EZ29U-0007xs-Cg for qemu-devel@nongnu.org; Mon, 07 Nov 2005 03:14:52 -0500 Received: from [62.242.22.158] (helo=router.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.36 #1) id 1EZ29S-0004pT-00 for qemu-devel@nongnu.org; Mon, 07 Nov 2005 09:14:50 +0100 Received: from nelson.home.kernel.dk ([192.168.0.33] helo=kernel.dk) by router.home.kernel.dk with esmtp (Exim 4.22) id 1EZ29Q-0006UT-UZ for qemu-devel@nongnu.org; Mon, 07 Nov 2005 09:14:48 +0100 Date: Mon, 7 Nov 2005 09:15:56 +0100 From: Jens Axboe Subject: Re: [Qemu-devel] Audio cd's in guest OS Message-ID: <20051107081555.GA3699@suse.de> References: <4ad99e050511040447t5c334aaeh51d28d1ff92bf43e@mail.gmail.com> <79bf98480511040940q789072cbrf4b1603eb2415fdd@mail.gmail.com> <4ad99e050511050208i2585817dv13ce92634e31927c@mail.gmail.com> <436C98F0.7030307@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <436C98F0.7030307@gmx.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Sat, Nov 05 2005, Oliver Gerlich wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Lars Roland schrieb: > > On 11/4/05, Mike Swanson wrote: > > > >>I've found on systems where traditional rippers don't work (eg, > >>cdparanoia), CDFS has a greater chance of ripping the CDs (by default > >>into WAV, but you can enable an option to rip it in the pure CDDA > >>format if you want). > > > > > > Thanks - I should have known that someone had made a file system for > > this. However I still think it would be great to be able to pass the > > actual /dev/cdrom on to the guest OS, but I must admit that I have not > > grasped the complexity yet on doing this, so I am going to do some > > Qemu code reading before continuing - I am not even sure if it can be > > done in VMWare although I seam to remember that Windows as a host OS > > running VMWare allows the guest access to a audio cdrom. > > > > Not sure how VMware does that; but actually I didn't even succeed > accessing /dev/cdrom on the host when an audio cd is inserted: > > dd if=/dev/hdc of=/dev/null bs=2352 count=1 > dd: reading `/dev/hdc': Input/output error > 0+0 records in > 0+0 records out > 0 bytes transferred in 0.077570 seconds (0 bytes/sec) > > I used a blocksize of 2352 because I've read that's the size for audio > cds... It didn't work with bs=1 either. While the block size you gave is correct for cdda frames, you cannot read them this way. The commands you use for reading data from a data track varies, and the CDROM driver will always use the READ_10 command for io originating from the file system layer. You would also need to put some effort into the page cache to allow non-power-of-2 block sizes for this to work. So it's not trivial :-) For reading audio tracks, you can use either some pass through command mechanism like CDROM_SEND_PACKET or SG_IO. Or the CDROMREADAUDIO ioctl, which is the easiest to use since it doesn't require an understanding of the command set. -- Jens Axboe