Hi everyone. I hope I'm posting on the correct subforum. I have a USB Speaker "Logitech Laptop Speaker Z205" that have only USB port to plug, no jack. Both power and audio go though the USB port. The speaker have a DAC inside in order to work. The speaker uses Windows generic drivers.
I connected the speaker to my laptop and sniffed the packets sent though USB with USBPCap and Wireshark. I played a short 16bit 44.1kHz WAV file and capture what was sent to the speakers.
I compared the hex value of the wav file to the USB data and they were different. What I mean with this is that searching a random 3 byte string of a wav file most likely end in "No results found" in Wireshark. I'm tryng to figure out what the driver does to the audio data before sending it over to the USB.
[I want to know this because I have to code a microcontorller (PIC32) driver so that the PIC can stream audio into the speakers]
I also don't know if the driver sends the wav header or not. I'm newbie on audio stuff. Any help is appreciated
I connected the speaker to my laptop and sniffed the packets sent though USB with USBPCap and Wireshark. I played a short 16bit 44.1kHz WAV file and capture what was sent to the speakers.
I compared the hex value of the wav file to the USB data and they were different. What I mean with this is that searching a random 3 byte string of a wav file most likely end in "No results found" in Wireshark. I'm tryng to figure out what the driver does to the audio data before sending it over to the USB.
[I want to know this because I have to code a microcontorller (PIC32) driver so that the PIC can stream audio into the speakers]
I also don't know if the driver sends the wav header or not. I'm newbie on audio stuff. Any help is appreciated
Quite possibly you're seeing the result of up-sampling from 44.1k to 48k that Windows forces for most output devices. Try doing it using WASAPI to stream at native sample rate if you're on Vista or higher or convert your file to 48k first using something like SoX resampler. Be interested to see your result!
Thanks! You were right. Windows drivers up-sample the audio to 48kHz.
I up-sampled the wav to 48kHz and then searched for a small string in the old capture (when I streamed 44.1). I found the string.
Also I noticed the streamed bits were not exactly the same. Sometimes you get a different byte, 1 bit increase or 1 bit decrease.
I couldn't find a pattern for these increases/decreases.
I also made a capture of the new 48kHz wav streamed and compare it to the wav. I thought this time these 1bit increases/decreases wouldn't exist. Strange enough, I couldn't match even a small random string between the wav and the capture.
Now I'm moving my effort to understand more about USB. Thanks for the help.
I'll leave the audio samples and the captures attached in this post, just in case someone arrives here from Google years later.
I up-sampled the wav to 48kHz and then searched for a small string in the old capture (when I streamed 44.1). I found the string.
Also I noticed the streamed bits were not exactly the same. Sometimes you get a different byte, 1 bit increase or 1 bit decrease.
I couldn't find a pattern for these increases/decreases.
I also made a capture of the new 48kHz wav streamed and compare it to the wav. I thought this time these 1bit increases/decreases wouldn't exist. Strange enough, I couldn't match even a small random string between the wav and the capture.
Now I'm moving my effort to understand more about USB. Thanks for the help.
I'll leave the audio samples and the captures attached in this post, just in case someone arrives here from Google years later.
That sounds like progress then! Can't think of a reason for those +/-1 bit differences really.
The difference between the streamed 48k wav and the original wav data may be from the Windows or music player volume controller. If the signal is being passed with any kind of attenuation then the digital data would also change. Kernel streaming may be the only way to guarantee streaming is occurring with no attenuation, 0dBfs level, although it is possible that setting your Windows and music player sliders to full will work! I found S/PDIF streaming was attenuated by 6dB even at 'full', presumably as headroom for the result of system sounds being mixed over music playback, however USB could achieve 0dBfs playback from a music source so you might be lucky.
BTW, I'm curious why your up-sampled clip is sped up? This isn't a normal result of up-sampling, looking on foobar the number of samples is identical on the 44.1 and 48k wavs, you'd typically expect the 48k wav to contain more data.
The difference between the streamed 48k wav and the original wav data may be from the Windows or music player volume controller. If the signal is being passed with any kind of attenuation then the digital data would also change. Kernel streaming may be the only way to guarantee streaming is occurring with no attenuation, 0dBfs level, although it is possible that setting your Windows and music player sliders to full will work! I found S/PDIF streaming was attenuated by 6dB even at 'full', presumably as headroom for the result of system sounds being mixed over music playback, however USB could achieve 0dBfs playback from a music source so you might be lucky.
BTW, I'm curious why your up-sampled clip is sped up? This isn't a normal result of up-sampling, looking on foobar the number of samples is identical on the 44.1 and 48k wavs, you'd typically expect the 48k wav to contain more data.
- Status
- Not open for further replies.