Re: What's happened to CDIOCREADAUDIO friends?
On Tue, Sep 23, 2003 at 09:54:06PM -0400, Michael W. Oliver wrote: Content-Description: signed data Well, I didn't know somebody was patching it, so I started using the following in ripit.pl (not exactly as below) instead of 'dagrab': dd if=/dev/acd0t01 ibs=2352 obs=2048 | sox -t raw -r 44100 \ -s -c 2 -w - -t wav -r 44100 -s -c 2 -w track01.wav Funny thing is, it is a hell of a lot faster than dagrab was. Before, dagrab would read the data in at about the same rate as flac would encode it, but now I can rip a 12 track disc in the time it takes flac to encode the first 6 tracks. Go figure... dagrab reads each block of data multiple times until it gets identical results. The code mentions jitter correction but doesn't include any detailed explanation. For a more equitable comparison, I suggest you hack dagrab.c:cd_read_audio() to use read() ISO ioctl(). Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
On Wed, 24 Sep 2003 01:29:15 +0300 (EEST) Vladimir Kushnir [EMAIL PROTECTED] wrote: [XMMS/etc patches] Unfortunately, no. But I can post them - they're not big (obviously :-) I would be particularly interested in the XMMS patch. Regards, Julian Stecklina -- Think. Think think. Think said Pooh, and got a headache. pgp0.pgp Description: PGP signature
Re: What's happened to CDIOCREADAUDIO friends?
I'm sorry bothering you with this again, but what's the desision with sys/cdio.h? I'm hoing to submit patches to XMMS and XINE folks, but in both enabling/disabling CDDA is based on this ioctl's presence. BTW, if anybody's interested I've patched audio/dagrab, audio/cdparanoia and multimedia/xmms (actually, CVS version but that shouldn't matter) so they work with CDDA now. On Sat, 20 Sep 2003, Soren Schmidt wrote: [Discussion omitted] Excuse me ? AFAIK we are the *only* OS with the CDIOCREADAUDIO interface. I should know since I put the code in the ATAPI driver way back when our device system couldn't handle != %DEV_BSIZE requests. Anyhow, its been ages since it was announced that there is a new and right way to grap audio, that noone hasn't cared about it, well... So stop whining and get the port maintainers to fix the ports that breaks because of this (it would maybe even reduce the diffs :) ). Regards, Vladimir ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
On Tuesday 23 September 2003 23:47, Vladimir Kushnir wrote: I'm sorry bothering you with this again, but what's the desision with sys/cdio.h? I'm hoing to submit patches to XMMS and XINE folks, but in both enabling/disabling CDDA is based on this ioctl's presence. BTW, if anybody's interested I've patched audio/dagrab, audio/cdparanoia and multimedia/xmms (actually, CVS version but that shouldn't matter) so they work with CDDA now. Do you have the patches available online? Arjan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
Unfortunately, no. But I can post them - they're not big (obviously :-) On Wed, 24 Sep 2003, Arjan van Leeuwen wrote: On Tuesday 23 September 2003 23:47, Vladimir Kushnir wrote: I'm sorry bothering you with this again, but what's the desision with sys/cdio.h? I'm hoing to submit patches to XMMS and XINE folks, but in both enabling/disabling CDDA is based on this ioctl's presence. BTW, if anybody's interested I've patched audio/dagrab, audio/cdparanoia and multimedia/xmms (actually, CVS version but that shouldn't matter) so they work with CDDA now. Do you have the patches available online? Vladimir ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
Well, I didn't know somebody was patching it, so I started using the following in ripit.pl (not exactly as below) instead of 'dagrab': dd if=/dev/acd0t01 ibs=2352 obs=2048 | sox -t raw -r 44100 \ -s -c 2 -w - -t wav -r 44100 -s -c 2 -w track01.wav Funny thing is, it is a hell of a lot faster than dagrab was. Before, dagrab would read the data in at about the same rate as flac would encode it, but now I can rip a 12 track disc in the time it takes flac to encode the first 6 tracks. Go figure... If anyone is interested in the exact changes that I made to use 'dd', as well as jacking in flac, let me know. Nothing special as I am not a programmer at all, but I am managing thanks to your help. -- Mike perl -e 'print unpack(u,88V]N=%C=\!I;F9O(EN(AE861EG,*);' pgp0.pgp Description: signature
Re: What's happened to CDIOCREADAUDIO friends?
It seems Vladimir Kushnir wrote: Together with sys/cdio.h, where both ioc_read_audio and CDIOCREADAUDIO are declared I'll get rid of those... Again, a pity. What benefits do we gain here? Speed? CDDA extraction never required all that much of it, and to be honest the difference will hardly be measurable. The only thing it will give is (once again) an interface completely different from other OSs (== some extra pain for developers == fewer applications). Excuse me ? AFAIK we are the *only* OS with the CDIOCREADAUDIO interface. I should know since I put the code in the ATAPI driver way back when our device system couldn't handle != %DEV_BSIZE requests. Anyhow, its been ages since it was announced that there is a new and right way to grap audio, that noone hasn't cared about it, well... So stop whining and get the port maintainers to fix the ports that breaks because of this (it would maybe even reduce the diffs :) ). -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
It seems Vladimir Kushnir wrote: The right way of doing audio graps has been to set the wanted blocksize with CDRIOCSETBLOCKSIZE (not needed if all tracks on the CD is of the same size), then just read from the device. Ioctl's was newer meant to be used to read/write data, its also faster to use the R/W path... Ok, perhaps, but ioctls seem to be more usual way and it's a bit simpler... Still, I'm just user... Rather unhappy now :-( I disagree, but that another matter.. How about just doing: dd if=/dev/acdXtY of=trackY bs=2352 Now that cant be simpler and is already present... Together with sys/cdio.h, where both ioc_read_audio and CDIOCREADAUDIO are declared I'll get rid of those... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
On Fri, 19 Sep 2003, Soren Schmidt wrote: I disagree, but that another matter.. How about just doing: dd if=/dev/acdXtY of=trackY bs=2352 Now that cant be simpler and is already present... In XMMS/XINE/cdda2wav/cdparanoia/...? Lots of programs depend on this interface, and not just ports (== patches), but programs. I'd thought the right way would be to _first_ announce this greakage and give at least maintainers time to write down patches, and _then_ break all those ports. How about POLA? Together with sys/cdio.h, where both ioc_read_audio and CDIOCREADAUDIO are declared I'll get rid of those... Again, a pity. What benefits do we gain here? Speed? CDDA extraction never required all that much of it, and to be honest the difference will hardly be measurable. The only thing it will give is (once again) an interface completely different from other OSs (== some extra pain for developers == fewer applications). Regards, Vladimir ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
It seems Vladimir Kushnir wrote:
Hello,
We used to have this ioctl in old ATA/ATAPI driver (and still do in
sys/cdio.h); apparently, it's no longer there with ATAng. Is this a bug or
feature? And if this was planned what's going to replace it? As it is,
this change has broken cdparanoia cooked ioctls interface (BTW, that's why
it doesn't work without root privileges), xmms and xine CDDA support and
The right way of doing audio graps has been to set the wanted blocksize
with CDRIOCSETBLOCKSIZE (not needed if all tracks on the CD is of
the same size), then just read from the device. Ioctl's was newer meant
to be used to read/write data, its also faster to use the R/W path...
perhaps several more ports. Oh, incidentaly, cdparanoia (at least) is
broken under -CURRENT in yet another way: it still looks for
/dev/{acd,cd,mcd}%c -
ports/audio/cdparanoia/files/patch-interface-scan_devices.c
- which aren't there after cloning removal).
Then that should be fixed as well the sooner the better...
-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
On Thu, 18 Sep 2003 00:16:17 +0300 (EEST) Vladimir Kushnir [EMAIL PROTECTED] wrote: Hello, We used to have this ioctl in old ATA/ATAPI driver (and still do in sys/cdio.h); apparently, it's no longer there with ATAng. Is this a bug or feature? And if this was planned what's going to replace it? As it is, this change has broken cdparanoia cooked ioctls interface (BTW, that's why it doesn't work without root privileges), xmms and xine CDDA support and perhaps several more ports. That is why Digital Audio Extraction does not work with XMMS anymore? It's kind of annoying if you do not have your CD-ROM drive connected to the soundcard... :) Regards, Julian -- Death is just Nature's way of saying, Hey! You're not alive anymore! pgp0.pgp Description: PGP signature
Re: What's happened to CDIOCREADAUDIO friends?
On Thu, Sep 18, 2003 at 08:17:16AM +0200, Soren Schmidt wrote: The right way of doing audio graps has been to set the wanted blocksize with CDRIOCSETBLOCKSIZE (not needed if all tracks on the CD is of the same size), then just read from the device. Ioctl's was newer meant to be used to read/write data, its also faster to use the R/W path... I'm sure users will see it as a functional regression, though. It might not be the 'right' API for it, I agree, but it would save our user base screaming if the functionality were preserved (or at least emulated). BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's happened to CDIOCREADAUDIO friends?
On Thu, 18 Sep 2003, Soren Schmidt wrote:
The right way of doing audio graps has been to set the wanted blocksize
with CDRIOCSETBLOCKSIZE (not needed if all tracks on the CD is of
the same size), then just read from the device. Ioctl's was newer meant
to be used to read/write data, its also faster to use the R/W path...
Ok, perhaps, but ioctls seem to be more usual way and it's a bit
simpler... Still, I'm just user... Rather unhappy now :-(
perhaps several more ports. Oh, incidentaly, cdparanoia (at least) is
broken under -CURRENT in yet another way: it still looks for
/dev/{acd,cd,mcd}%c -
ports/audio/cdparanoia/files/patch-interface-scan_devices.c
- which aren't there after cloning removal).
Then that should be fixed as well the sooner the better...
Together with sys/cdio.h, where both ioc_read_audio and CDIOCREADAUDIO are
declared
Regards,
Vladimir
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
What's happened to CDIOCREADAUDIO friends?
Hello,
We used to have this ioctl in old ATA/ATAPI driver (and still do in
sys/cdio.h); apparently, it's no longer there with ATAng. Is this a bug or
feature? And if this was planned what's going to replace it? As it is,
this change has broken cdparanoia cooked ioctls interface (BTW, that's why
it doesn't work without root privileges), xmms and xine CDDA support and
perhaps several more ports. Oh, incidentaly, cdparanoia (at least) is
broken under -CURRENT in yet another way: it still looks for
/dev/{acd,cd,mcd}%c -
ports/audio/cdparanoia/files/patch-interface-scan_devices.c
- which aren't there after cloning removal).
Regards,
Vladimir
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
