1 |
Mark Knecht schreef: |
2 |
> On 9/29/05, Holly Bostick <motub@××××××.nl> wrote: |
3 |
> |
4 |
>> Mark Knecht schreef: |
5 |
>> |
6 |
>>> On 9/28/05, Mark Knecht <markknecht@×××××.com> wrote: |
7 |
>>> |
8 |
>>> |
9 |
>>>> Great. Tried it. It worked fine and didn't upset Jack which |
10 |
>>>> means my experiment goes on. |
11 |
>>>> |
12 |
>>>> This is working so much better for me than Gnome on my AMD64 |
13 |
>>>> box. I'll have to go back and try the standard Gentoo kernel |
14 |
>>>> instead of ck-sources. |
15 |
>>>> |
16 |
>>>> <snip> |
17 |
>>>> |
18 |
>>> In the end the xruns came back so FVWM-Crystal didn't magically |
19 |
>>> solve my problems. (unfortunately...) |
20 |
>>> |
21 |
>>> My quest goes on. Now running 2.6.14-rc2-mm1, looking for |
22 |
>>> 2.6.14-rc2-mm1-rt6 |
23 |
>>> |
24 |
>> |
25 |
>> Am I the only one who doesn't know what are 'xruns'? Whatever they |
26 |
>> are, it would seem that the problem can be minimized, but not |
27 |
>> eliminated by choice of WM, but obviously we couldn't go any |
28 |
>> further in actually eliminating them without knowing what they are |
29 |
>> (or at least I couldn't, since I don't actually know what you're |
30 |
>> referring to). |
31 |
>> |
32 |
>> Holly |
33 |
> |
34 |
> |
35 |
> Holly, I'm so very sorry. Of course you would have no reason to know |
36 |
> about xruns if you are not part of the Linux audio community. My |
37 |
> apologies. |
38 |
> |
39 |
> One of the Linux 'methods', if you will, for moving audio between |
40 |
> sound cards and applications is a server called Jack (jackd) which is |
41 |
> supplied by emerging jack-audio-connection-kit. Jack provides for |
42 |
> the movement of digital audio between a sound card and essentially an |
43 |
> unlimited number of apps (really 'ports') with a known latency. It's |
44 |
> the latency that's really important to those of us doing live |
45 |
> recording. If I'm listening to a piano and recording my guitar then I |
46 |
> need the two to sound like they are in time or it is virtually |
47 |
> impossible to play a part correctly. |
48 |
> |
49 |
> An 'xrun', standing I think for overrun - go figure - is when |
50 |
> something in the system has not taken or delivered digital audio at |
51 |
> the agreed upon time. This leads to clicks and pops. If you were to |
52 |
> look at the waveform in an oscilloscope there would be some sort of |
53 |
> discontinuity. |
54 |
> |
55 |
> With my 32-bit machines I have been blessed. I have been able, for at |
56 |
> least the last year, to run the standard Gentoo kernel at <3mS |
57 |
> latency with no xruns. I've been writing and recording music on |
58 |
> Gentoo and had no problems while others running on other distros have |
59 |
> had to build specialized kernels utilizing patches from Andrew Morton |
60 |
> and Ingo Molnar to get equivalent results. On guy in Australia didn't |
61 |
> really beleive me so I helped him build a Gentoo box over the net. |
62 |
> When that machien came up it worked so well, with the standard |
63 |
> kernel, that he converted all the machines in his studio to Gentoo |
64 |
> and no brags about how stable his environment is. |
65 |
> |
66 |
> I looked forward to such an experience with my new AMD64 machine. It |
67 |
> did not come to be true. |
68 |
> |
69 |
> Every 64-bit kernel I've tried so far either has terrible xrun |
70 |
> problems or will not build. This includes: |
71 |
> |
72 |
> gentoo-sources - xruns ck-sources - xruns kernel.org - 2.6.13.3 & |
73 |
> 2.6.14-rc2 - xruns 2.6.14-rc2-rt6 - Ingo's patches - won't build |
74 |
> |
75 |
> I'm currently running 2.6.14-rc2-mm1 - with Andrew Morton's patches. |
76 |
> I have not yet tested it but at least it built. |
77 |
> |
78 |
> The major change to the kernel to get better real time results is |
79 |
> (apparently) to make pretty much everything preemptable. When Ingo's |
80 |
> patches are added then a new preemption model shows up in make |
81 |
> menuconfig. Unfortunately for me it won't build on 64-bit yet, at |
82 |
> least for me. |
83 |
> |
84 |
> The window manager choice is just one choice those of us playing with |
85 |
> low latency audio make. KDE has never worked well for me. Gnome has |
86 |
> been fine for the last year until this new AMD64 experience. In the |
87 |
> old days we used fluxbox over KDE and Gnome and got good, but not |
88 |
> great, results. |
89 |
> |
90 |
> Anyway, I hope that helps explain my xrun comments. |
91 |
> |
92 |
|
93 |
OK, sorry not to snip, but your post is a continuous |
94 |
thought/explanation, and it doesn't seem right-- and I don't top-post |
95 |
(99% of the time). |
96 |
|
97 |
I have several questions mostly leading to the same ultimate end. But |
98 |
only one is important to express: |
99 |
|
100 |
1) do you actually need X? i.e., is it possible to record audio in the |
101 |
manner that you do without it? |
102 |
|
103 |
What occurs to me, looking in from outside, is that while your issues |
104 |
are clearly known to be kernel-based, and 64-bit based, the fact that |
105 |
you are using programs that interfere with latency/real-time issues is |
106 |
obfuscating the entire problem. Certainly if the choice of window |
107 |
managers has an effect on the severity of the problem. |
108 |
|
109 |
So clear the waters if you can, because you can't solve a problem that |
110 |
you can't clearly see the outlines of. |
111 |
|
112 |
Can you record audio from the command line? Or do the X-based programs |
113 |
you use run under DirectFB? What I'm getting at is getting rid of all |
114 |
the obstructions that could possibly interfere with the kernel and |
115 |
introduce even more latency issues than what it already has, so that you |
116 |
(or any devs) can see what problems it already has distinctly enough to |
117 |
solve them-- or to eliminate them sufficiently so that you can get on |
118 |
with doing what you do until the kernel stabilizes so you can use it |
119 |
normally. |
120 |
|
121 |
I mean, X is a horrible hog, heaven only knows what effect your nVidia |
122 |
or ATI kernel modules may be having on the ability of the kernel to |
123 |
behave properly, since they also make demands on the kernel that |
124 |
'distract' it, as it were. And if Jack is a daemon (which I know it is), |
125 |
it's not like it needs X for itself. |
126 |
|
127 |
It's of course quite possible that I'm talking out of my butt, since I |
128 |
am not a member of the Linux audio community, but I do know that the |
129 |
first step in troubleshooting is to simplify the environment as much as |
130 |
possible, and then slowly increase the complexity to see when and where |
131 |
things break down. |
132 |
|
133 |
Were I you, I would consider: |
134 |
|
135 |
- If keeping X, switching to the absolute most minimal wm possible |
136 |
(twm, ratpoison, ion), to see what effect that had. |
137 |
- If downstepping from X, investigating what programs run under |
138 |
DirectFB and seeing what effect that had. |
139 |
- If going cold-turkey off X, seeing how far you get with the |
140 |
command-line and ncurses programs. |
141 |
|
142 |
Am I, in fact, talking out of my butt (since it seems that the 'real' |
143 |
audio community would have tried at least some of this)? Or are there |
144 |
reasons that this simplification process is not possible for |
145 |
professional audio recording? |
146 |
|
147 |
Holly |
148 |
|
149 |
|
150 |
-- |
151 |
gentoo-user@g.o mailing list |