#44 Stuck B3 notes

admin
closed-fixed
5
2009-05-30
2009-05-15
Andrew C
No

Some notes randomly stick on the B3 emulation.

Could this be due to latency (I'm running in JACK with a -count of 1024), or is it a bug?

Andrew.

Discussion

1 2 3 4 > >> (Page 1 of 4)
  • Nick Copeland

    Nick Copeland - 2009-05-15

    What do you play the B3 with? You have an external keyboard. I use both but generally using qwerty for testing. You might want to try using -mididbg to see note events and see if bristol sees the sticky notes but does not react or whether it never gets to see the events.

    What does your CPU load look like when you use the b3? The gearbox is quite intensive and could be related.

    Regards, Nick.

     
  • Nick Copeland

    Nick Copeland - 2009-05-15
    • milestone: --> admin
    • assigned_to: nobody --> ncopeland
     
  • Nobody/Anonymous

    Nick,

    I do use an externel keyboard. Here's the some of the output of -mididbg:

    midiNoteOn ch 0: 53, velocity 62
    midiNoteOff ch 0: 53, velocity 64
    midiNoteOn ch 0: 53, velocity 65
    midiNoteOff ch 0: 53, velocity 64
    midiNoteOff ch 0: 53, velocity 64

    The second midiNoteOff, is I think when I have to press the key again, to stop it from sounding.
    My CPU looks fine, I'm running a 2.2Ghz PC here!

    Andrew

     
  • Nick Copeland

    Nick Copeland - 2009-05-16

    I don't think the issue is directly related to Jack or this count size - this is the default I get from jack and is all I ever use to test the jack drivers. Admittedly, I mostly work with ALSA native and 256 samples so let me check it out some more.

    The debug output is odd:

    midiNoteOn ch 0: 53, velocity 62 - note 53 on
    midiNoteOff ch 0: 53, velocity 64
    midiNoteOn ch 0: 53, velocity 65
    midiNoteOff ch 0: 53, velocity 64 - note 53 off
    midiNoteOff ch 0: 53, velocity 64 - note 53 off second time

    This looks like it lost a noteOn event? Do you also use the -midi jack option? I will to do more testing here with my keyboards and Jack and see what happens - the key assignment code is sometimes a bit gruesome and bugs have crept in there from time to time.

    Regards, Nick

     
  • Nick Copeland

    Nick Copeland - 2009-05-16

    Andrew,

    I can't reproduce this, it works here, just spent I am not sure how long playing away with Jack and the B3 to clean up some of the default memories (specifically the first memory) to make it more jazzy and less rocky.

    No stuck notes though.

    Nick

     
  • Andrew C

    Andrew C - 2009-05-17

    Hmm. I think it might be my midi controllers.. I played the opening 12 bars of 'Green Onions' on my qwerty keyboard and no stuck notes, but when I go to my controllers, I start getting stuck notes..

    Either this is a problem with my 'boards or perhaps the midi management code in Bristol??

    Andrew.

     
  • Nick Copeland

    Nick Copeland - 2009-05-17

    The brighton code actually sends midi note on/off from the interpreted qwerty keypress events. They do go over a TCP link rather than serial line.

    Having said that I would not rule out issues with the low level bristol midi drivers, it happens but I do get it here with my controllers, admittedly they are all USB rather than MIDI interfaces.

    I can see about getting you some debug code such that the bristol midi library does a hex dump of every byte that comes in over the interface at the lowest level, that way we might get to see what is going on, ie, if it is in the driver then dumping the hex data will show which events arrive and which are maybe corrupted in the the code path.

    Do you have any other synths you could test with the same controller and MIDI cable? If there is noise in the cable it can result in lost events but this is often also audible with other problems: the wrong notes get sounded, the key velocity jumps around occasionally sounding very low or very high volumes. In this case the wrong played notes are relevant - if I get a midi note off that has the wrong key id I cannot turn the note off - if it wasn't the one that was played I cannot track it down.

    Will let you know when I have some code - next couple of days or so.

    Nick

     
  • Nobody/Anonymous

    Nick,

    I probably should've mentioned that I have no other problems with the cable/controller, because I can use a variety of other synths/sample players on linux (zynaddsubfx, linuxsampler) and even other bristol synths! IIRC, even the other organs (vox/vox300) didn't have any stuck notes... Just the B3...

    Andrew.

     
  • Nick Copeland

    Nick Copeland - 2009-05-17

    Hi Andrew,

    Perhaps it is the B3 then - it uses a big hulking piece of code to generate all 92 tonewheels when any key is pressed, it even generates the keys you don't play since there may well be crosstalk from wheels that do not actually pass your drawbar selection. If you do this for 1024 samples at a time there is the possibility that the serial interface suffers overruns - one byte does not get read out of the UART before the next one arrives and overwrites it. If you lose a byte of a midi message then it does not make much sense if you only have the other 1 or 2 bytes from the message.

    Do you run jack and bristol as root? That would affect realtime priority. Do you have a laptop with CPU frequency control? That can affect CPU availability for some events.

    Now the 'gearbox' does not run in 'real time', it runs a lot faster, far longer than the time between two MIDI bytes but even then it should not affect interrupt driven serial IO. This could still be the cause, especially with root permissions and running with RT scheduling or a variable CPU clock speed.

    Regards,

    Nick

     
  • Nick Copeland

    Nick Copeland - 2009-05-17

    On top of that, 1024 samples is a lot of latency. I don't agree that a synth needs to run with 'ms' latency using 16 or 32 samples per period however 1024 is still quite high for playing in real time, you are at the point where the delay from playing a key to hearing a sound become audible - you are at 50ms with two buffers. It can be masked by the fact that travel time on a keyboard is the same order of magnitude admittedly.

    There are some theoretical performance enhancements I could put into the gearbox generation, it involves delayed waveform generation, ie, only build a wave on demand if it is required by a note, drawbar, crosstalk, etc. I have no idea how much CPU it would free up, it would not improve the sound quality (*) and seeing as most of the net talk lately is for emulators other than bristol then anything that does not improve the sound does not really have much demand at the moment.

    * The Hammond emulation could also do with

    1. better valve overdrive
    2. some stronger code for the leslie
    3. a couple of reworks for vibrachorus

    These would improve the sound but I am short of time to work on them.

    Regards, Nick.

     
  • Nobody/Anonymous

    Maybe if I turn off the 'preacher' option in the B3, maybe that'd lessen the CPU load?

    Also, the Qjackctl window says something like (5.3ms) after the JACK commandline. I'm not running windows atm, so I'll have to report back tommorrow.

    Well, are there any other native linux B3 emulations on the 'net?
    Personally, while I would use a B3 VSTI under linux, I prefer not running them in WINE and to (as Bristol does) have an automap feature.

    Andrew.

     
  • Nick Copeland

    Nick Copeland - 2009-05-17

    Yes, if you disable the preacher option then the code just generates 9 waveforms per note, its a lot more efficient and a lot cleaner, more synth like. Nothing wrong with that it just not so realistic. It will help to know if it makes a difference though.

    There are other B3 emulations under Linux, horgand, stygmorgan, gmorgan (these are the same code I think) then you have various C Sound emulators which are highly rated although I doubt if they do what the preacher can, and probably the best is beatrix however it is not open source and is no longer maintained. As far as I know it was incorporated in a hammond playalike box which is why the code is no longer maintained - does not support jack or even ALSA as far as I know.

    What is your MIDI interface, is it USB or a really 5 pin DIN round midi connector? Do you use realtime scheduling, ie, run as root? There is something odd about the 5.3 ms, that would imply a buffer size of 256 samples, not 1024.

    Regards, Nick.

     
  • Nobody/Anonymous

    My midi interface is USB and I don't run as root, but I do use real-time scheduling.

    Andrew.

     
  • Nobody/Anonymous

    Is this a problem on my end? Or can you reproduce this bug?
    While I do use a USB midi interface to transfer notes from my keyboard to the PC, I doubt it's a problem with the cable and/or controller...

    Andrew.

     
  • Nick Copeland

    Nick Copeland - 2009-05-19

    Hi Andrew,

    It is not reproducible here but I agree it is not a problem with either the cable or the controller. I was interested as to whether it happened with a smaller number of samples, 256 or 128 say, since I think you have a point regarding latency. If this is the case I will have to review what can be done about it: if it comes down to processing time in Bristol causing serial overruns (in this case USB serial) with RT prioritised audio processing then reducing the processing time will change that characteristic. The reduction can either come from fewer samples at a time or by optimising the code however as I said, those optimisations are a little way off at the moment.

    Do you have a multicore system or single CPU? You said it was 2.2GHz, just curious as to whether it is a Duo or not. If it has dual CPU but they are hyperthreads then it will not change that much. This is visible in /proc/cpuinfo.

    Regards, Nick.

     
  • Nick Copeland

    Nick Copeland - 2009-05-20

    Hi Andrew,

    I am adding some more capabilities to the MIDI debuging code that is available from -mididbg, it will help to locate whether messages are being delivered to the library but lost in the engine. There are quite a few changes to several files which means it is a little difficult to distribute them in advance.

    Regards, Nick.

     
  • Nobody/Anonymous

    Cool, hopefully the new debugging code will enable me to see if the messages are being sent (or not as the case seems).

    Also, maybe you could (if it's at all possible) to just zip up the entire source tree you're working on and e-mail it to me? or perhaps provide a diff .patch against 0.40.2?

    Andrew.

     
  • Nick Copeland

    Nick Copeland - 2009-05-21

    Hi Andrew,

    You should be able to download the following file:

    http://bristol.sourceforge.net/files/bristol-0.40.3b.tar.gz

    For the midi debugging you need two more flags:

    startBristol -jack -b3 -mididbg2 -activesense 0

    Debug2 has midi debuging that includes hex dumps on a byte per byte basis so if there are occasional lost data they should show up here. You need to disable active sensing since otherwise you get a lot of background messages that go between the GUI and engine so they can detect each other. The output will look something like this from playing one note from each manual of the B3 from the GUI:

    (3)90 (3)39 (3)78 midiNoteOn (54) ch 0: 57, velocity 120
    (3)80 (3)39 (3)78 midiNoteOff (55) ch 0: 57, velocity 120
    (3)91 (3)39 (3)78 midiNoteOn (56) ch 1: 57, velocity 120
    (3)81 (3)39 (3)78 midiNoteOff (57) ch 1: 57, velocity 120

    The the first bracketed number is the 'handle', this is a midi device ID from the MIDI library, not a midi channel but you should see different handles for the GUI and the ALSA Seq for you controller. The brackets following the event are the sequence number, between them it should be possible to see if bytes are lost or if whole messages are lost (from missing sequence numbers). The sequence numbers are not applied to sysex events, they are delivered to a different set of routines but you still get the hexdumps of them.

    Regards, Nick.

     
  • Nobody/Anonymous

    uh oh, i'm missing brightonSID2.c:
    if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/X11R6/include -Wall -g -I./../include/brighton -I./../include/bristol -DBRISTOL_HAS_ALSA=1 -g -O2 -I/usr/X11R6/include -MT brightonSID2.o -MD -MP -MF ".deps/brightonSID2.Tpo" -c -o brightonSID2.o brightonSID2.c; \ then mv -f ".deps/brightonSID2.Tpo" ".deps/brightonSID2.Po"; else rm -f ".deps/brightonSID2.Tpo"; exit 1; fi
    brightonSID2.c:29:26: error: brightonSID2.h: No such file or directory
    brightonSID2.c:797:2: warning: #warning this index has changed
    brightonSID2.c:803:2: warning: #warning this index has changed too
    brightonSID2.c: In function 'sid2Configure':
    brightonSID2.c:2067: error: 'sid2Mem' undeclared (first use in this function)
    brightonSID2.c:2067: error: (Each undeclared identifier is reported only once
    brightonSID2.c:2067: error: for each function it appears in.)
    make[2]: *** [brightonSID2.o] Error 1
    make[2]: Leaving directory `/tmp/bristol-0.40.3/brighton'
    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory `/tmp/bristol-0.40.3'
    make: *** [all] Error 2

    Andrew

     
  • Nobody/Anonymous

    well brightSID2.h rather. :-P

     
  • Nick Copeland

    Nick Copeland - 2009-05-21

    Oops, my bad - development code again, I did not put the header file in the Makefile.am so then it does not get included in the tarball. I really should get used to using 'make distcheck' rather than 'make dist'!

    Another version out there:

    http://bristol.sourceforge.net/files/bristol-0.40.3c.tar.gz

    This slightly changes the debug output - it had too many brackets, and I have just added in SYSEX reporting although they still do not get a sequence number.

    Regards, Nick

     
  • Nick Copeland

    Nick Copeland - 2009-05-21

    Do you use an RT patched kernel? Also, when the audio thread starts you should get the following message:

    rescheduled thread: 75

    The last number is the relative scheduling priority.

    Regards, Nick.

     
  • Nobody/Anonymous

    yeah, it's at 75.

    Also, should the debug output dump to file or what?

    Andrew.

     
  • Nick Copeland

    Nick Copeland - 2009-05-21

    The debug output only dumps to the terminal. You can try

    startBristol -jack -b3 -activesense 0 -mididbg2 | tee /tmp/debug.out

    The output gets a bit gory since multiple process are writing to the output and tee jumbles them up even more than I do but you do get a copy on disk.

    Regards, Nick.

     
  • Nobody/Anonymous

    Ok, cool..

    Unfortunatly, after trying this, I'm still not enlightened about why this is going wrong..
    The output isn't exactly helpful...

     
1 2 3 4 > >> (Page 1 of 4)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks