Verrry eeeenteresting (showing my age):
Kdiff3 if fantastic. Looked at the entire source tree for -rt1 and -rt7. Found
nothing changed touching any of the "oopses" that I have seen. What has been
added, however, seems to be the trace-back code to display them. (Hypervisor
code has been removed but my PIII clunker has no kvm support in any event.)
Am I correct?
These displayed "oopses" are problematic or simply debugging messages?
They seem to not have effected anything outside of my log files :-)
Safe to ignore them and keep using -rt7 or wait on this?
Quoting dfro(a)umich.edu:
> I am having trouble finding and controlling where an audio file ends
> during export. I will go to export a small one second sample, for
> example, and the cursor keeps going on and on making a large file where
> there is no sound. I click on the keyboard 'goto end' key and it sends
> me to a measure hundreds of measures away from the beginning. Why?
>
> Can someone help me understand how to control where the end of a sound
> file is. How do I invoke the 'end' marker or change its location?
The end of an Ardour session is controlled by the marker labelled "end"
which should be present for every session. Drag that marker to the position
you want the exporting to and.
The same applies to the "start" marker except that it controls the start of
the session.
Sampo
>Ran for nearly two hours with none. Nada.
>Then they started up again. What triggered them?
>The only thing in the logcheck at the same time as the first outputs was a
>pptp connect after the original connection fell. Relevant?
The offending functions are icmp_.... functions, most likely the more used
ipv4 flavor of icmp.c.
Example:
BUG: using smp_processor_id() in preemptible [00000000] code: IRQ-9/1110
caller is icmp_xmit_unlock+0xb/0x30
[<c01faab9>] debug_smp_processor_id+0xa9/0xb0
[<c02e531b>] icmp_xmit_unlock+0xb/0x30
[<c02e598e>] icmp_send+0x11e/0x3f0
....
Ran for nearly two hours with none. Nada.
Then they started up again. What triggered them?
The only thing in the logcheck at the same time as the first outputs was a
pptp connect after the original connection fell. Relevant?
Hi,
I have a DVD-Audio disc with 5.1 channel audio which I can't play
using my standalone DVD player (it doesn't support DVD-A) so I was
wondering, is here any way I can play this in my Linux machine
(providing I have a multichannel audio interface, of course)? I don't
seem to find any DVD-A software player and the DVD players like
mplayer and Totem only play the 2-channel+video version that it's also
included in the disc (inside the VIDEO_TS directory). I can see
several .aob files in the AUDIO_TS directory, is there any way of
ripping the 6 channels out of these files in case there is no direct
way of playing them?
Thanks!
Hector
--
===============================
http://www.hcenteno.net
Grame is pleased to announce the release of Faust 0.9.9.1.
Faust is a functional programming language for real-time signal
processing and synthesis that targets high-performance audio processing
applications and plugins. The Faust compiler translates Faust programs
into optimized C++ code for a variety of audio platforms : Jack, Alsa,
OSS, Ladspa, VST, MaxMSP, Q, PD, SuperCollider, etc.
What's new ?
------------
- Pattern Matching : introduction of pattern matching based definitions,
a powerful programming technique used in many modern functional
programming languages like Q, Haskell, ML, CAML, Clean, etc.
- Support for QT4 applications : two new architecture files have been
added to generate native QT4 applications : jack-qt.cpp and alsa-qt.cpp.
Use 'make jackqt' and 'make alsaqt' in the examples folder to generate
QT4 applications.
- Improved GTK support : all GTK architecture files have been updated to
correct the reversed vertical slider issue.
- 64-bits compatibility : the Faust compiler and the generated C++ code
are now fully 64-bits compatible.
- Improved Max/Msp support : the compilation process has been
simplified. It now directly uses gcc instead of xcode projects. It is
based on Max/MSP 4.6 SDK and generates universal binary .mxo on Intel
platforms.
Acknowledgments
---------------
We are grateful to all the contributors of this new release, with a
special mention to A. Graef for the implementation of the Pattern
Matching extension.
Useful links :
--------------
Web site : http://faust.grame.fr
Download :
http://downloads.sourceforge.net/faudiostream/faust-0.9.9.1.tar.gz
Y. Orlarey
Hi all,
I would like to compose a music that could fit in a ocean documentary..with
fishes, dolphins, whales, etc..
I would like to find related sound..
Synthesizers, effects, sea sounds, waves, dolphin sounds, bubbles, sand,
submarine, breath of a diver..etc..
Do you happen to know the Deep blue soundtrack by Eric Serra?
I would like to find these kind of sounds..
Any idea? Soundfonts? ZynAdd presets? Drumkits?
Thank you very much!
Julien.
>Also does it. Did not see any on bootup (rt4 had loads) but I have them on
>logchecks. Stuff like:
>May 28 17:12:54 d_baron kernel: [<c01faab9>]
debug_smp_processor_id+0xa9/0xb0
>May 28 17:12:54 d_baron kernel: .. [<c01faa5f>] ....
> ******
>May 28 17:12:54 d_baron kernel: BUG: using smp_processor_id() in preemptible
>[00000000] code: IRQ-9/1114
>May 28 17:12:54 d_baron kernel: caller is icmp_push_reply+0x25/0x190
>May 28 17:12:54 d_baron kernel: [<c02e5105>] icmp_push_reply+0x25/0x190
>May 28 17:12:54 d_baron kernel: [<c02e5b36>] icmp_send+0x2c6/0x3f0
>May 28 17:12:54 d_baron kernel: [<e1392755>] _nv005692rm+0x75/0xa0 [nvidia]
>May 28 17:12:54 d_baron kernel: [<c0142b02>] add_preempt_count+0x12/0xe0
>May 28 17:12:54 d_baron kernel: [<e130ff82>] _nv004775rm+0x1e/0x48 [nvidia]
>May 28 17:12:54 d_baron kernel: [<c030b0a4>] rt_read_unlock+0x24/0x50
>May 28 17:12:54 d_baron kernel: [<e0b0d75b>] ipt_do_table+0x21b/0x350
>[ip_tables]
>May 28 17:12:54 d_baron kernel: [<e130478c>] _nv007481rm+0x38/0x60 [nvidia]
>THese are all over the place. They apparently all touch on smp. Maybe this
>kernel should be build without SMP (multiprocessor) support (Debian kernels
>have this by default now!).
And obviously involves the nvidia (their older 9631 propietary) driver. What
ip_tables is doing here? Maybe the IRQ of the agp and the network card are
being shared?
-rt1 did not have any of these problems.
dmesg has all of them (without the times) if anyone working on this is
interested.
BTW, kernel seems to be working OK otherwize.
Also does it. Did not see any on bootup (rt4 had loads) but I have them on
logchecks. Stuff like:
May 28 17:12:54 d_baron kernel: [<c01faab9>] debug_smp_processor_id+0xa9/0xb0
May 28 17:12:54 d_baron kernel: .. [<c01faa5f>] ....
debug_smp_processor_id+0x4f/0xb0
May 28 17:12:54 d_baron kernel: [<c01faa6d>] debug_smp_processor_id+0x5d/0xb0
May 28 17:12:54 d_baron kernel: [<c01faab9>] debug_smp_processor_id+0xa9/0xb0
May 28 17:12:54 d_baron kernel: .. [<c01faa5f>] ....
debug_smp_processor_id+0x4f/0xb0
May 28 17:12:54 d_baron kernel: [<c01faab9>] debug_smp_processor_id+0xa9/0xb0
May 28 17:12:55 d_baron kernel: .. [<c01faa5f>] ....
debug_smp_processor_id+0x4f/0xb0
May 28 17:12:55 d_baron kernel: [<c01faab9>] debug_smp_processor_id+0xa9/0xb0
These repeat.
May 28 17:12:54 d_baron kernel: BUG: using smp_processor_id() in preemptible
[00000000] code: IRQ-9/1114
May 28 17:12:54 d_baron kernel: caller is icmp_push_reply+0x25/0x190
May 28 17:12:54 d_baron kernel: [<c02e5105>] icmp_push_reply+0x25/0x190
May 28 17:12:54 d_baron kernel: [<c02e5b36>] icmp_send+0x2c6/0x3f0
May 28 17:12:54 d_baron kernel: [<e1392755>] _nv005692rm+0x75/0xa0 [nvidia]
May 28 17:12:54 d_baron kernel: [<c0142b02>] add_preempt_count+0x12/0xe0
May 28 17:12:54 d_baron kernel: [<e130ff82>] _nv004775rm+0x1e/0x48 [nvidia]
May 28 17:12:54 d_baron kernel: [<c030b0a4>] rt_read_unlock+0x24/0x50
May 28 17:12:54 d_baron kernel: [<e0b0d75b>] ipt_do_table+0x21b/0x350
[ip_tables]
May 28 17:12:54 d_baron kernel: [<e130478c>] _nv007481rm+0x38/0x60 [nvidia]
THese are all over the place. They apparently all touch on smp. Maybe this
kernel should be build without SMP (multiprocessor) support (Debian kernels
have this by default now!).
-rt1 did not have any of these problems.
dmesg has all of them (without the times) if anyone working on this is
interested.
BTW, kernel seems to be working OK otherwize.