On Tue 06 November 2012 01:12:42 Daniel Mack wrote:
On 05.11.2012 23:29, Jeffrey Barish wrote:
On Mon 05 November 2012 16:03:00 Daniel Mack wrote:
Hi Jeff,
On 05.11.2012 02:53, Jeffrey Barish wrote:
On Sun 04 November 2012 11:39:48 Daniel Mack wrote:
[cc alsa-devel]
On 04.11.2012 02:25, Jeffrey Barish wrote:
On Fri 26 October 2012 15:21:06 Jeffrey Barish wrote:
On Fri 26 October 2012 21:47:05 Daniel Mack wrote:
On 26.10.2012 21:43, Jeffrey Barish wrote:
On Thu 25 October 2012 19:10:45 Daniel Mack wrote:
On 25.10.2012 17:18, Jeffrey Barish wrote:
I found something in the snd_usb_audio code (in endpoint.c) that
could
explain one of the problems I have observed (the ticks). I would
normally test my theory by modifying the code. In this case, I
would
like to stick in a print statement to see what values are being
assigned
to certain variables. Unfortunately, I am too ignorant to do
something
even this trivial as I have never worked on kernel code. I think
I
am
supposed to use printk,
printk is nice for simple debugging, yes. But note that this call
is
timing critical and should not be used in fast path code.
Introducing
a printk for each received packet for example will almost
certainly
make
the driver behave quite differently.
but beyond that I am lost. Can someone provide
me with some directions? I need to know how to make the driver.
To
that
end, I probably will have to install additional packages. After
making
the driver, I need to know how to install it over the existing
driver.
Here's one way to do it:
1. git clone
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
(your
patch should apply on top of this tree eventually)
2. cd sound
3. zcat /proc/config.gz .config
4. build and install the kernel image. How that is done depends on
the
distribution you're using. For Ubuntu follow the docs at [1]
(start
at
point #5). For Fedora and others, something like make make
install
should do
5. reboot and check that the new kernel is running
6. hack on sound/usb
7. make M=sound/usb
8. reload the module with sudo rmmod snd_usb_audio; sudo insmod
sound/usb/snd-usb-audio.ko (better plug out the device before so
you
always have the same defined point of start)
Hope that works for you.
Daniel
[1] https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
Your directions were almost perfect, so even I was able to build
the
kernel. I made a discovery using the new kernel that might help
someone
more familiar with the code than I am to localize the problem. I
am
still hearing the blip when I play audio sampled at 88.2 kHz, but I
just
noticed that the blip is perfectly periodic, with a period of about
16.4
seconds. I am playing a sine wave synthesized using GStreamer
using
the
following command:
gst-launch audiotestsrc volume=0.01 ! audio/x-raw-float, width=64,
rate=88200, channels=2, endianness=1234 ! audioconvert ! alsasink
A sine wave makes it easier to hear the blip. Does this clue
suggest
anything?
I also want to mention that when I use the new kernel, I do not get
the
ticks at either 88.2 or 96 kHz even when I do not use the external
USB
hub. I plan next to back up to the 3.6.2 kernel to see whether I
still
get ticks there.
Which kernel did you use when you heard the 'blibs'?
The latest news is bad. I am on 3.2.0 now. The USB DAC is working
perfectly at this moment at both 96 kHz and 88.2 kHz without the
external
USB hub (imagine calling that bad news). If I set the srate to 88.2
kHz
and stop and start the sine wave, sometimes I get the blip. Forget
about
its being periodic. It was definitely periodic before lunch; now I
usually
get random intervals if I get any blips at all. As I am typing this
message, I can't get blips at all. There was some correlation
between
changing sample rates and blips, but I can't reproduce that behavior
now.
What is most weird is that I haven't gotten any ticks since lunch
with
any
kernel or with either sample rate, yet they were reliable earlier
today
unless I used the external USB hub. I obviously need to experiment
some
more to see whether I can observe a pattern.
To conclude (?) this thread, I am now convinced that the anomalies I
observed were unrelated to the device driver. I had two theories
remaining. One was that the problem was somehow related to an
overheating problem. I used a heat gun to convince myself that the
theory was wrong. The other was that the problem had something to do
with services running in the background that interfered with the
device
driver. I removed or disabled all services that I could identify as
superfluous. Removed services include zeitgeist, apparmor,
modemmanager,
mdadm, and bluetooth. Disabled services include atd, dns-clean, and
