Re: [LAD] snd-usb-audio dying on jackd xruns
Rods Bobavich wrote: USB interface is any one of the M-Audio Line. FastTrack USB, FastTrack Pro, MobilePre USB... In other words multiple interfaces have been tested. This problem is specific to this machine... ALSA urb.c:480: frame 0 active: -75 Thank you for not mentioning this message on alsa-devel. In the context of USB, the error code -75 means babble, which is a technical term from the USB specification that means that the device sent some data at a time when it shouldn't (or at least the controller thinks so). ALSA urb.c:146: timeout: still 7 active urbs.. ALSA urb.c:146: timeout: still 2 active urbs.. ALSA pcm.c:223: 4:2:1: usb_set_interface failed As a result of that, the USB controller driver gets wedged. This looks like a hardware problem with your USB controller. Please try the latest kernel; there were added some workarounds recently. You might also try connecting the device through a hub (but there are some bugs in the EHCI driver which might make it think that it cannot schedule enough bandwidth for full duplex). CE: hpet increased min_delta_ns to 7500 nsec It seems that the error happened about the time of the hpet increase. Do we have a timer problem? No, this has nothing to do with USB. This message typically occurs on AMD system with C1E enabled, and is harmless. Regards, Clemens -- Don't anthropomorphize computers; they don't like it. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] snd-usb-audio dying on jackd xruns
On 02/03/2011 12:40 AM, Rods Bobavich wrote: One is PCI Express USB 3.0 You don't have to test that one, it most probably won't work. Best, Jeremy ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] snd-usb-audio dying on jackd xruns
I got a new PCI USB 2.0 card and now I'm running Jackd at -n2 -p64. I figured this was a hardware glitch. Thanks for confirming... I'll still run debug on this and report. Which kernel did you want me to test? ...Rods ;-) On Thu, Feb 3, 2011 at 01:22, Clemens Ladisch clem...@ladisch.de wrote: Rods Bobavich wrote: USB interface is any one of the M-Audio Line. FastTrack USB, FastTrack Pro, MobilePre USB... In other words multiple interfaces have been tested. This problem is specific to this machine... ALSA urb.c:480: frame 0 active: -75 Thank you for not mentioning this message on alsa-devel. In the context of USB, the error code -75 means babble, which is a technical term from the USB specification that means that the device sent some data at a time when it shouldn't (or at least the controller thinks so). ALSA urb.c:146: timeout: still 7 active urbs.. ALSA urb.c:146: timeout: still 2 active urbs.. ALSA pcm.c:223: 4:2:1: usb_set_interface failed As a result of that, the USB controller driver gets wedged. This looks like a hardware problem with your USB controller. Please try the latest kernel; there were added some workarounds recently. You might also try connecting the device through a hub (but there are some bugs in the EHCI driver which might make it think that it cannot schedule enough bandwidth for full duplex). CE: hpet increased min_delta_ns to 7500 nsec It seems that the error happened about the time of the hpet increase. Do we have a timer problem? No, this has nothing to do with USB. This message typically occurs on AMD system with C1E enabled, and is harmless. Regards, Clemens -- Don't anthropomorphize computers; they don't like it. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAA] gst123-0.1.4
Hi! On Wed, Jan 26, 2011 at 08:25:22AM -0800, Niels Mayer wrote: Here's one more backtrace that's even more interesting. Perhaps a varargs error: see gst_structure_id_set_valist() ?? ... The problem is that the three backtraces you sent me point to different locations; one of them actually has a gst123 function in it, the other two backtraces only include symbols of the gstreamer libs. Now of course it could be that gst123 does something wrong (has a bug), and that only some time after the actual bug occurred an unrelated function crashes due to memory corruption. Or it could be that gst123 has nothing to do with any of it, and that some part of the GStreamer framework causes the crash; for instance a decoding plugin, an audio driver or whatever. So one way to proceed would be to try to reproduce the same bug with another GStreamer based player. If that succeeds, gst123 is not the problem. If it fails, we probably cannot say for sure if gst123 is the problem, because gst123 may be using GStreamer in a different but equally valid way. In any case, your stack traces have given me the opportunity of reading the code in gst123 a few more times, and I've done two changes; one of them should make gst123 abort with an assertion if the code is problematic, the other change should fix a possible crash, but I am not sure if that is the crash you had. But it would be great if you reran your test with the newest gst123 git version. Generally, valgrind would also be a great tool for debugging such problems, however, I suppose it won't be fast enough to play your radio stream... Cu... Stefan -- Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Files: Bpm tagging
On 2/3/2011 1:14 PM, Stefan Kost wrote: On 02/03/2011 09:27 PM, Bearcat M. Sandor wrote: On 2/2/2011 2:43 PM, Stefan Kost wrote: Am 16.01.2011 17:42, schrieb Harry Van Haaren: Hey guys, I'm looking for the lowest-common-denominator of audio file formats that handle BPM info. mp3, wav, vorbis, mp4, mkv files can have BPM metadata (according to my grep in the gstreamer source code). GStreamer has a bpm detector as well. Stefan What? No love for my favorite, wavpack? Wavpack never gets any respect! :( Bearcat M. Sandor Erm, it should work already. From the wavpack homepage: Uses ID3v1 and APEv2 tags for metadata (including ReplayGain) Both are well supported by gstreamer. :) Stefan Thank you Stefan, The bpm detection, tagging is not working in banshee. I'll do some sniffing around and see why that might be. Thanks, Bearcat M. Sandor ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Meego pulseaudio compliance and enforcement (was Re: [Meego-handset] Enabling Speakerphone)
On Wed, Feb 2, 2011 at 12:48 PM, Stefan Kost enso...@hora-obscura.de wrote: Sorry for the very late reply. One thing to mention is that the CPU load for pulse is going wown quite a bit when plugin headphones. Otherwise it runs some extra processing needed to accomodate the speakers. Since there is a lot of extra audio processing going on, would employing a library like nova-simd, announced below, help out with the situation -- e.g. writing the handset speaker-equalization and some of the audio mixing functionality using more efficient instructions? What looks interesting is the claimed support for both ARM Neon, Altivec, and Atom: See http://tim.klingt.org/code/projects/nova-simd/repository and forwarded announcement below. Regarding pulseaudio, in http://code.google.com/p/ytd-meego/wiki/CitizenJournalismWithYoutubeDirectForMeego#Pulseaudio:_Connecting_Audio_Subsystem,_Microphone_and_Speakers -- Note all the ins and outs back and forth between kernel and user space. Architecturally, the system seems inverted, especially since you have to go back out to ALSA for bluetooth. Why not keep it all in kernel space?? Or better yet: employ analog mixing and multiple DAC's -- only one or two needing to be hi-fi and the others for notifications and telephony can be quite cheap low-rate, low-accuracy DAC's and ADC's. Yes analog mixing and routing is hard to do in a mixed signal environment; but is the power consumption of a few DACs and op-amps even close to that of needing a fraction of the CPU running constantly just to do what a few resistors and an op-amp can do? To say nothing about the potential sound quality improvement of not needing to resample any of the mixed outputs, nor worry about synchronizing or locking rates between different subsystems, and all the other benefits of analog summing: http://emusician.com/mag/emusic_sum_tracks/ ... (hopefully the flamewars that will ensue about this controversial topic will cancel out the flamewars on pulseaudio :-) ) . What I'm proposing for the low-power/handset world isn't that far off from the audio system needed back when CPU's had computational power that made digital mixing for notifications, telephony, or music playback unthinkable: the analog mixing built into the http://en.wikipedia.org/wiki/AC'97 spec (and associated hardware), but updated for the handset world. I'm sure that's not going to happen anytime soon, but I can dream? ... Anyways, here's the announcement: http://music.columbia.edu/pipermail/andraudio/2011-February/98.html .. [andraudio] nova-simd suite updated for arm neon Dan Stowell Thu Feb 3 04:48:36 EST 2011 Hi - nova-simd is a C++ header-only template library for taking advantage of SIMD instructions in the kind of DSP processes used in audio processing (i.e. not just basic stuff like vectorised mul+add and loop unrolling, but also some more audio-specific things like ramps, distortions). It's created by Tim Blechmann and it lives here: http://tim.klingt.org/code/projects/nova-simd/repository It was originally implemented for SSE and SSE2 - we use it in SuperCollider and it gives us massive performance improvements on intel chips. We've just added NEON (and Altivec) implementations too, so we should be able to boost performance on android and ios. The ARM NEON support is new and doesn't yet implement all the speedups, but should be useful for anyone wanting to implement C++ DSP for Android devices with SIMD speedups - especially if you're thinking about cross-platform code since the API is implemented for other chips too. Dan . Niels http://nielsmayer.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
