USB transfer_buffer allocations on 64bit systems
in [Kernel]
|
Prev: mfd: Initialise WM831x IRQ masks on chip even if interrupts not in use
Next: INFO: task apache2:7601 blocked for more than 120 seconds.
From: Daniel Mack on 11 May 2010 12:20 On Tue, May 11, 2010 at 12:06:09PM -0400, Alan Stern wrote: > On Wed, 12 May 2010, FUJITA Tomonori wrote: > > > > > Can you tell me all the exact process of DMA that the usb core and the > > > > driver do? > > > > > > 1. The audio driver stores data in urb->transfer_buffer. > > > > How urb->transfer_buffer is allocated? > > By kmalloc(). Right, Daniel? Yes, and that's precisely the reason for the whole thread ;) [...] > > The driver does only DMA_TO_DEVICE? Or you see DMA problems only with > > DMA_TO_DEVICE? > > The particular test that Pedro is running uses audio output only -- > he's sending sound data to a speaker and it comes out noisy. > > But the audio data has to come from somewhere, and I don't remember > where. Pedro, does the noise occur only when you're playing sound that > comes from a different USB device? What happens if you play sounds > that are stored on your hard disk, like an MP3 file? AFAIK that was playback from a file, yes. It would be interesting to have some results for the other direction as well, that's true. Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pedro Ribeiro on 11 May 2010 13:00 On 11 May 2010 17:06, Alan Stern <stern(a)rowland.harvard.edu> wrote: > > The particular test that Pedro is running uses audio output only -- > he's sending sound data to a speaker and it comes out noisy. > > But the audio data has to come from somewhere, and I don't remember > where. �Pedro, does the noise occur only when you're playing sound that > comes from a different USB device? �What happens if you play sounds > that are stored on your hard disk, like an MP3 file? > Or what happens if you take the incoming sound data and store it in a > disk file, and then later play that file out through the speaker? > > Alan Stern > > I'm clueless about the whole underlying process but I don't think it is related to playing a file from the disk or another USB device. I don't need to play any file for this interference to be heard - I just need to "open" the device. By this I mean that if I create a JACK server or if I open the device using the ALSA backed in a program like Mixxx I immediately start hearing the cracks and pops in the speaker. But to answer your question, playing a file from the hard drive using aplay I can also hear the interference - but only when the sound is playing. As soon as the sound stops and the audio device is "closed", no interference occurs. However, when using the JACK server, which probably opens and polls the audio card constantly (its a low latency audio server) I don't even need to be playing any sound for the interference to be constant. I can also see it since I have 4 output leds in the USB audio card and even if I'm only using 2 channels, the 4 channel leds light up with interference as the sound cracks and pops. Regards, Pedro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Mack on 11 May 2010 13:20 On Tue, May 11, 2010 at 05:48:11PM +0100, Pedro Ribeiro wrote: > I'm clueless about the whole underlying process but I don't think it > is related to playing a file from the disk or another USB device. > > I don't need to play any file for this interference to be heard - I > just need to "open" the device. By this I mean that if I create a JACK .... which will stream zeros. Sure, that should also trigger the bug then. > server or if I open the device using the ALSA backed in a program like > Mixxx I immediately start hearing the cracks and pops in the speaker. > But to answer your question, playing a file from the hard drive using > aplay I can also hear the interference - but only when the sound is > playing. As soon as the sound stops and the audio device is "closed", > no interference occurs. Yes, because the stream is stopped, pending URBs are unlinked etc. That's completely expected. > However, when using the JACK server, which probably opens and polls > the audio card constantly (its a low latency audio server) I don't > even need to be playing any sound for the interference to be constant. That shouldn't affect the driver itself but just put the ALSA core under pressure. > I can also see it since I have 4 output leds in the USB audio card and > even if I'm only using 2 channels, the 4 channel leds light up with > interference as the sound cracks and pops. No surprise here. The 4 channels are mux'ed in an interleaved fashion, so if the buffers contain rubbish, you will hear artefacts on all channels. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pedro Ribeiro on 11 May 2010 13:40 On 11 May 2010 18:10, Daniel Mack <daniel(a)caiaq.de> wrote: > On Tue, May 11, 2010 at 05:48:11PM +0100, Pedro Ribeiro wrote: >> I'm clueless about the whole underlying process but I don't think it >> is related to playing a file from the disk or another USB device. >> >> I don't need to play any file for this interference to be heard - I >> just need to "open" the device. By this I mean that if I create a JACK > > ... which will stream zeros. Sure, that should also trigger the bug > then. > >> server or if I open the device using the ALSA backed in a program like >> Mixxx I immediately start hearing the cracks and pops in the speaker. >> But to answer your question, playing a file from the hard drive using >> aplay I can also hear the interference - but only when the sound is >> playing. As soon as the sound stops and the audio device is "closed", >> no interference occurs. > > Yes, because the stream is stopped, pending URBs are unlinked etc. > That's completely expected. > >> However, when using the JACK server, which probably opens and polls >> the audio card constantly (its a low latency audio server) I don't >> even need to be playing any sound for the interference to be constant. > > That shouldn't affect the driver itself but just put the ALSA core under > pressure. > >> I can also see it since I have 4 output leds in the USB audio card and >> even if I'm only using 2 channels, the 4 channel leds light up with >> interference as the sound cracks and pops. > > No surprise here. The 4 channels are mux'ed in an interleaved fashion, > so if the buffers contain rubbish, you will hear artefacts on all > channels. > > Daniel > > So what would be the testcase you would like me to try? Pedro -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Mack on 11 May 2010 13:40
On Tue, May 11, 2010 at 06:32:50PM +0100, Pedro Ribeiro wrote: > On 11 May 2010 18:10, Daniel Mack <daniel(a)caiaq.de> wrote: > > No surprise here. The 4 channels are mux'ed in an interleaved fashion, > > so if the buffers contain rubbish, you will hear artefacts on all > > channels. > > So what would be the testcase you would like me to try? Would be good to see what happens if you could record audio (with arecord would be sufficient), just to see whether the same problem exists in the other direction. Either record an externally generated sine tone and open the resulting wave file in an editor. With the amount of artefacts you describe, they should easily be visible. Another option is to play back any kind of recorded audio thru an audio device that does not show the problem (some internal, onboard device?). Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |