audiocd kioslave in kde4
Chris Burel
chrisburel at gmail.com
Mon Apr 13 09:46:37 BST 2009
Hmm, more troubles. I installed a new HAL (0.5.12rc1), and now my
system actually recognizes all 143 of my devices, instead of the 5 it
saw before. But then I got this:
#0 0xb7f13424 in __kernel_vsyscall ()
#1 0xb65a6bb9 in raise () from /lib/libc.so.6
#2 0xb65a8138 in abort () from /lib/libc.so.6
#3 0xb7d20f0d in qt_message_output () from /opt/qt/lib/libQtCore.so.4
#4 0xb7d20ff1 in qFatal () from /opt/qt/lib/libQtCore.so.4
#5 0xb7d2109c in qt_assert_x () from /opt/qt/lib/libQtCore.so.4
#6 0xb7cd057a in QList<QString>::operator[] (this=0x9624628, i=0) at
/opt/qt-4.5.0/include/QtCore/qlist.h:403
#7 0xb7ccc9a9 in AudioCD::AudioCDProtocol::initRequest
(this=0xbfa2e9c8, url=@0xbfa2e8ac)
at /usr/src/rpm/build/kdemultimedia-4.2.2/kioslave/audiocd/audiocd.cpp:341
#8 0xb7cccd79 in AudioCD::AudioCDProtocol::listDir (this=0xbfa2e9c8,
url=@0xbfa2e8ac)
at /usr/src/rpm/build/kdemultimedia-4.2.2/kioslave/audiocd/audiocd.cpp:564
#9 0xb788ae94 in KIO::SlaveBase::dispatch () from
/opt/kde-4.2.2/lib/libkio.so.5
#10 0xb7885aa4 in KIO::SlaveBase::dispatchLoop () from
/opt/kde-4.2.2/lib/libkio.so.5
#11 0xb7ccee66 in kdemain (argc=4, argv=0x959af60) at
/usr/src/rpm/build/kdemultimedia-4.2.2/kioslave/audiocd/audiocd.cpp:90
#12 0x0804dced in launch ()
#13 0x0804e44d in handle_launcher_request ()
#14 0x0804e910 in handle_requests ()
#15 0x0804f05c in main ()
Line 341 of audiocd.cpp is looking into templateTitels, which was
undefined. I traced the problem back to line 218,
#if defined(HAVE_CDDA_IOCTL_DEVICE)
When I recompiled I noticed I got the warning
#warning audiocd ioslave is not going to work for you
which I found odd because
> ldd /opt/kde-4.2.2/lib/kde4/kio_audiocd.so | grep cdd
libcdda_paranoia.so.0 => /usr/lib/libcdda_paranoia.so.0 (0xb7eb6000)
libcdda_interface.so.0 => /usr/lib/libcdda_interface.so.0 (0xb7ea6000)
So I configured my cxx flags to pass -DHAVE_CDDA_IOCTL_DEVICE and
recompiled. Now I can see the drive in dolphin with all the folders
like you'd expect (although all the .wav files are in the root dir, eg
"audiocd:/Track 01.wav"). I tried ripping wav, ogg vorbis, mp3, and
flac. All of them worked except mp3, which of course is the one I'm
really interested in. It creates an mp3 file, that does correspond to
the source cd (has breaks in the sound at the right points), but it's
just white noise. Here's the output from kdeinit4 when I rip an mp3:
Checking /dev/cdrom for cdrom...
Testing /dev/cdrom for SCSI/MMC interface
SG_IO device: /dev/sr1
CDROM model sensed sensed: SONY DVD-ROM DDU1612 DYS1
Checking for SCSI emulation...
Drive is ATAPI (using SG_IO host adaptor emulation)
Checking for MMC style command set...
Drive is MMC style
DMA scatter/gather table entries: 1
table entry size: 131072 bytes
maximum theoretical transfer: 55 sectors
Setting default read size to 27 sectors (63504 bytes).
Verifying CDDA command set...
Expected command set reads OK.
kio_audiocd(4538) AudioCD::AudioCDProtocol::initRequest: dir= "MP3/"
file= "Track 06.mp3" req_track= 5 which_dir= 0 full CD?= false
kio_audiocd(4538) EncoderLame::receivedStderr: Lame stderr: Assuming
raw pcm input file : Forcing byte-swapping
LAME 3.98.2 32bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding <stdin> to /tmp/kde-cburel/kio_audiocdwX4538.mp3
Encoding as 44.1 kHz stereo MPEG-1 Layer III VBR(q=2)
kio_audiocd(4538) EncoderLame::processExited: Lame Encoding process
exited with: 0
I can successfully rip to .wav and then run
lame <file>.wav <file>.mp3
to get a good mp3 file. So I'm pretty sure it's not my lame install.
I believe the problem is the "Assuming raw pcm input file : Forcing
byte-swapping" part. Is there any way to disable that parameter?
Am I going to bust anything by manually defining
HAVE_CDDA_IOCTL_DEVICE? Any ideas why that isn't set correctly?
Sorry for the size of the post, but I'm going for completeness here. :-)
On Sat, Apr 11, 2009 at 2:06 PM, Chris Burel <chrisburel at gmail.com> wrote:
>
> A more informative backtrace
> #0 0xb80bf424 in __kernel_vsyscall ()
> #1 0xb6752bb9 in raise () from /lib/libc.so.6
> #2 0xb6754138 in abort () from /lib/libc.so.6
> #3 0xb7eccf0d in qt_message_output () from /opt/qt/lib/libQtCore.so.4
> #4 0xb7eccff1 in qFatal () from /opt/qt/lib/libQtCore.so.4
> #5 0xb7ecd09c in qt_assert_x () from /opt/qt/lib/libQtCore.so.4
> #6 0xb5df986a in QList<QString>::at (this=0xbf8d872c, i=0) at /opt/qt-4.5.0/include/QtCore/qlist.h:395
> #7 0xb5df7d66 in KCompactDisc::defaultCdromDeviceName ()
> at /usr/src/rpm/build/kdemultimedia-4.2.2/libkcompactdisc/kcompactdisc.cpp:148
> #8 0xb5df7dd6 in KCompactDisc (this=0x97c794c, infoMode=KCompactDisc::Asynchronous)
> at /usr/src/rpm/build/kdemultimedia-4.2.2/libkcompactdisc/kcompactdisc.cpp:172
> #9 0xb7e7d5e2 in Private (this=0x97c78b8) at /usr/src/rpm/build/kdemultimedia-4.2.2/kioslave/audiocd/audiocd.cpp:106
> #10 0xb7e7a600 in AudioCDProtocol (this=0xbf8d8878, protocol=@0xbf8d88dc, pool=@0xbf8d88d4, app=@0xbf8d88cc)
> at /usr/src/rpm/build/kdemultimedia-4.2.2/kioslave/audiocd/audiocd.cpp:164
> #11 0xb7e7ac39 in kdemain (argc=4, argv=0x9771910)
> at /usr/src/rpm/build/kdemultimedia-4.2.2/kioslave/audiocd/audiocd.cpp:88
> #12 0x0804dced in launch ()
> #13 0x0804e44d in handle_launcher_request ()
> #14 0x0804e910 in handle_requests ()
> #15 0x0804f05c in main ()
>
> The problem is that KCompactDisc is not getting a list of devices back from Solid/HAL because HAL isn't detecting my cdrom.
> $> hal-device | grep ': udi'
> 0: udi = '/org/freedesktop/Hal/devices/computer_drm_r300_card0'
> 1: udi = '/org/freedesktop/Hal/devices/computer'
> 2: udi = '/org/freedesktop/Hal/devices/acpi_PWRF'
> 3: udi = '/org/freedesktop/Hal/devices/acpi_PWRB'
> 4: udi = '/org/freedesktop/Hal/devices/acpi_CPU1'
> 5: udi = '/org/freedesktop/Hal/devices/acpi_CPU2'
>
> That's why it's not working, but that shouldn't make audiocd crash. A more descriptive error message like "Couldn't detect cdrom device, check HAL configuration" would be nice.
>
> Should I submit a bug report?
>
> 2009/4/11 Thiago Macieira <thiago at kde.org>
>>
>> Chris Burel wrote:
>> >Hmm, that gives me a pretty worthless stacktrace:
>> >#0 0xb8076424 in __kernel_vsyscall ()
>> >#1 0xb6709e86 in kill () from /lib/libc.so.6
>> >#2 0x0804dcd5 in launch ()
>> >#3 0x0804e44d in handle_launcher_request ()
>> >#4 0x0804e910 in handle_requests ()
>> >#5 0x0804f05c in main ()
>>
>> You have to continue executing from there. That's the SIGSTOP signal that
>> the ioslave sends itself so that you can attach.
>>
>> >
>> >Although I do get this:
>> >ASSERT failure in QList<T>::at: "index out of range", file
>> >/opt/qt-4.5.0/include/QtCore/qlist.h, line 395
>> >
>> >I'd have to build a debug kdelibs to get a decent stacktrace?
>>
>> Not build, but at least have debug symbols. And, of course, for
>> kio_audiocd.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> PGP/GPG: 0x6EF45358; fingerprint:
>> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>>
>> _______________________________________________
>> kde-multimedia mailing list
>> kde-multimedia at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-multimedia
>>
>
More information about the kde-multimedia
mailing list