Can't get Bristol Started

Help
krisbee
2008-11-24
2013-05-23
1 2 > >> (Page 1 of 2)
  • krisbee

    krisbee - 2008-11-24

    Compiled without issue, but for some reason I can't get Bristol started... sorry for the noob problem... now, it says Bristol is already active, but it isn't actually...

    [krisbee2008@localhost ~]$ startBristol -b3
    generate bandwidth limited waveforms(31, 12)
    spawning midi thread
    Fixing samplerate at 44100
    midi sequencer
    Opened listening control socket: 5028
    midiOpen: bristol(100)
    Client ID = 128
    Queue ID = 0
    Registering 0 1
    Registered 128 0
    Device name "bristol" did not parse, defaults 128.0
    opened midi device: 0/1
    parent going into idle loop
    Got midi thread OK status
    bristol version 0.20.9
    connected to :0
    display is 1280 by 1024 pixels
    Window is w 1280, h 1024, d 24, 0 0 0
    Using DirectColor display
    alloc color by name Blue
    Initialise the hammondB3 link to bristol: 81338c0
    hostname is localhost, bristol
    TCP port: 5028
    Accepted connection from 0 (3) onto 2 (5)
    Connected to the bristol control socket: 4
    bristolengine already active
    created 32 voices: allocated 32 to synth
    spawning audio thread
    bristolAudioOpen(plughw:0,0, 44100, 256, 1200008)
    audioOpen(b7e041a0, 0, 1024): plughw:0,0
    opening device plughw:0,0, flags 0000000d
    open playback on plughw:0,0, pre 8
    Could not configure playback period size
    period size is -1208082192
    Problem opening audio device plughw:0,0, exiting audio thread
    could not get thread schedule
    Midi read retry (5591)
    Audio Thread status failed: exiting. Is device in use?
    Midi read retry (5591)
    parent exiting
    return - no data in buffer
    cleanupBrighton(0)
    cleared sigpipe handler
    cleanupBrighton(0)
    midi write error, fd 4, size 1
    return - no data in buffer
    socket closed
    request acked: -1
    [krisbee2008@localhost ~]$    

     
    • krisbee

      krisbee - 2008-11-24

      Oh, and here is the configure output, just so you know how it was built:
      [krisbee2008@localhost bristol-0.20.9]$ ./configure
      checking for a BSD-compatible install... /usr/bin/install -c
      checking whether build environment is sane... yes
      checking for gawk... gawk
      checking whether make sets $(MAKE)... yes
      checking build system type... i686-pc-linux-gnu
      checking host system type... i686-pc-linux-gnu
      checking for style of include used by make... GNU
      checking for gcc... gcc
      checking for C compiler default output file name... a.out
      checking whether the C compiler works... yes
      checking whether we are cross compiling... no
      checking for suffix of executables...
      checking for suffix of object files... o
      checking whether we are using the GNU C compiler... yes
      checking whether gcc accepts -g... yes
      checking for gcc option to accept ISO C89... none needed
      checking dependency style of gcc... gcc3
      checking for a sed that does not truncate output... /bin/sed
      checking for grep that handles long lines and -e... /bin/grep
      checking for egrep... /bin/grep -E
      checking for ld used by gcc... /usr/bin/ld
      checking if the linker (/usr/bin/ld) is GNU ld... yes
      checking for /usr/bin/ld option to reload object files... -r
      checking for BSD-compatible nm... /usr/bin/nm -B
      checking whether ln -s works... yes
      checking how to recognize dependent libraries... pass_all
      checking how to run the C preprocessor... gcc -E
      checking for ANSI C header files... yes
      checking for sys/types.h... yes
      checking for sys/stat.h... yes
      checking for stdlib.h... yes
      checking for string.h... yes
      checking for memory.h... yes
      checking for strings.h... yes
      checking for inttypes.h... yes
      checking for stdint.h... yes
      checking for unistd.h... yes
      checking dlfcn.h usability... yes
      checking dlfcn.h presence... yes
      checking for dlfcn.h... yes
      checking for g++... g++
      checking whether we are using the GNU C++ compiler... yes
      checking whether g++ accepts -g... yes
      checking dependency style of g++... gcc3
      checking how to run the C++ preprocessor... g++ -E
      checking for g77... no
      checking for xlf... no
      checking for f77... no
      checking for frt... no
      checking for pgf77... no
      checking for cf77... no
      checking for fort77... no
      checking for fl32... no
      checking for af77... no
      checking for xlf90... no
      checking for f90... no
      checking for pgf90... no
      checking for pghpf... no
      checking for epcf90... no
      checking for gfortran... no
      checking for g95... no
      checking for xlf95... no
      checking for f95... no
      checking for fort... no
      checking for ifort... no
      checking for ifc... no
      checking for efc... no
      checking for pgf95... no
      checking for lf95... no
      checking for ftn... no
      checking whether we are using the GNU Fortran 77 compiler... no
      checking whether  accepts -g... no
      checking the maximum length of command line arguments... 98304
      checking command to parse /usr/bin/nm -B output from gcc object... ok
      checking for objdir... .libs
      checking for ar... ar
      checking for ranlib... ranlib
      checking for strip... strip
      checking if gcc supports -fno-rtti -fno-exceptions... no
      checking for gcc option to produce PIC... -fPIC
      checking if gcc PIC flag -fPIC works... yes
      checking if gcc static flag -static works... no
      checking if gcc supports -c -o file.o... yes
      checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
      checking whether -lc should be explicitly linked in... no
      checking dynamic linker characteristics... GNU/Linux ld.so
      checking how to hardcode library paths into programs... immediate
      checking whether stripping libraries is possible... yes
      checking if libtool supports shared libraries... yes
      checking whether to build shared libraries... yes
      checking whether to build static libraries... yes
      configure: creating libtool
      appending configuration tag "CXX" to libtool
      checking for ld used by g++... /usr/bin/ld
      checking if the linker (/usr/bin/ld) is GNU ld... yes
      checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
      checking for g++ option to produce PIC... -fPIC
      checking if g++ PIC flag -fPIC works... yes
      checking if g++ static flag -static works... no
      checking if g++ supports -c -o file.o... yes
      checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
      checking dynamic linker characteristics... GNU/Linux ld.so
      checking how to hardcode library paths into programs... immediate
      appending configuration tag "F77" to libtool
      checking for gcc... (cached) gcc
      checking whether we are using the GNU C compiler... (cached) yes
      checking whether gcc accepts -g... (cached) yes
      checking for gcc option to accept ISO C89... (cached) none needed
      checking dependency style of gcc... (cached) gcc3
      checking for a BSD-compatible install... /usr/bin/install -c
      checking whether make sets $(MAKE)... (cached) yes
      checking X11/X.h usability... yes
      checking X11/X.h presence... yes
      checking for X11/X.h... yes
      checking X11/Xlib.h usability... yes
      checking X11/Xlib.h presence... yes
      checking for X11/Xlib.h... yes
      checking X11/Xutil.h usability... yes
      checking X11/Xutil.h presence... yes
      checking for X11/Xutil.h... yes
      checking X11/Xos.h usability... yes
      checking X11/Xos.h presence... yes
      checking for X11/Xos.h... yes
      checking X11/Xatom.h usability... yes
      checking X11/Xatom.h presence... yes
      checking for X11/Xatom.h... yes
      checking for pkg-config... /usr/bin/pkg-config
      checking pkg-config is at least version 0.9.0... yes
      checking for ALSA... yes
      checking for JACK... yes
      checking for JACK... yes
      configure: creating ./config.status
      config.status: creating Makefile
      config.status: creating libbrightonX11/Makefile
      config.status: creating libbrighton/Makefile
      config.status: creating libbristolaudio/Makefile
      config.status: creating libbristolmidi/Makefile
      config.status: creating libbristol/Makefile
      config.status: creating brighton/Makefile
      config.status: creating bristol/Makefile
      config.status: creating bin/startBristol
      config.status: creating config.h
      config.status: config.h is unchanged
      config.status: executing depfiles commands

      bristol 0.20.9 :

      | Build with ALSA support .............................. : true
      | Build with JACK support .............................. : true
      | Build with JACK MIDI support ......................... : true
      | Installing data into ................................. : /usr/local/share/bristol

       
    • Nick Copeland

      Nick Copeland - 2008-11-24

      The first thing you need to do is look for any idle bristol processes and kill them:

      ps aux | grep bristol

      Then kill the process given by the first number on the line where you see the bristol daemon:

      kill -9 <some number>

      You said that you don't have any, and that should be true but sometimes they hang around. The message saying the daemon is already active is kind of bogus - the startBristol script starts the bristol engine, then the GUI and this causes the GUI to always reports the engine as already active. I should remove it.

      After that you need to start it again - you will get different diags this time and they might be useful. You might also want to try '-pixmap' if you have a 64 bit distro this time. Do you use jack audio or is anything else using the audio thread? If somebody has the audio device already open then bristol always fails and it used to leave a daemon hanging around. This should have been fixed in the latest release (0.20.9) and from what you say that is the case.

      You might want to wait for a couple of minutes before restarting this time, just to make sure the TCP socket has cleared up completely. If the process exits correctly this is not an issue, when it fails then the Linux IP stack will not allow reuse of the socket for a while (you can overcome this by using another value in the '-port' option - give it an arbitrary number greater than 1024.

      Regards,

      Nick.

       
    • Nick Copeland

      Nick Copeland - 2008-11-24

      If you have jack installed and running so that multiple applications can share the audio device and all then this would cause the problem you are seeing. Try the '-jack' option for jack audio and see if that improves things.

      Regards, nick.

       
      • krisbee

        krisbee - 2008-11-25

        Nick,

        I tried with and without Jack, running -pixmap, and -port with a number greater than 1024... none of that worked...  I have also tried running oss on my machine and tryin
        g it, and also alsa with pulseaudio (normally I have that off), and still no go.

        I have also tried running as root and normal, and I have ps'd for bristol instances, and have found no others running.

        What am I doing wrong?

        Thanks in advance,
        Kris

         
    • Nick Copeland

      Nick Copeland - 2008-11-25

      PulseAudio would damage bristol's access to the audio device but if it isn't running that should not be the problem. There was a thread on the user newsgroup just a while back about how to remove it completely. I am not saying that should be necessary however audio work and having an audio desktop are probably conflictive. What about browsers and such that might have the device open?

      What soundcard do you have? The one message from above is a failure on the sample framing. This is reported only after the device has been opened and is from the ALSA drivers (in this case). What OS do you have, Ubuntu 8.10? What version of the ALSA drivers do you have? My /proc/asound/version shows 1.0.14 which is the latest I have tested with.

      Regards, nick.

       
    • Nick Copeland

      Nick Copeland - 2008-11-25

      Hi Kris,

      This came off the LAU group:

      "Pulseaudio itself is quite useful, though i don't use it myself. There however _is_ a problem with the ubuntu way of using it. They use a virtual PCM device for pulseaudio and make it the _default_ pcm device vie /etc/asound.conf. On my system this effectively kills all sound, as it uses the modem device i have in my system.. Thus all alsa app go through my onboard modem. I didn't find a way to change this. So in my login scripts i now have

      killall pulseaudio

      as an effective solution ;) Another would be to edit /etc/asound.conf"

      Perhaps we should have a look at /etc/asound.conf and make sure the devices are still useful for other apps. maybe Bristol just needs to be given an alternative device name rather than its default of plughw:0.0 when using ALSA?

      Regards.

       
      • krisbee

        krisbee - 2008-11-25

        Okay, I am definitely not running pulseaudio (never liked it, and it caused problems elsewhere, too)

        As for /etc/asound.conf, I don't have that, but do have /etc/asound/names, which I have listed at the bottom of this post...

        The sound driver that is showing is the nforce AC'97 (built into motherboard)

        From another post of yours:
        <i>What soundcard do you have? The one message from above is a failure on the sample framing. This is reported only after the device has been opened and is from the ALSA drivers (in this case). What OS do you have, Ubuntu 8.10? What version of the ALSA drivers do you have? My /proc/asound/version shows 1.0.14 which is the latest I have tested with. </i>

        I am using Mandriva 2008.1, and tried setting my system to OSS, with no help either.  From /proc/asound/version:
        Advanced Linux Sound Architecture Driver Version 1.0.16 (Tue Feb 05 09:31:00 2008 UTC).

        [krisbee2008@localhost etc]$ cat asound.names
        ctl {
                alsactl1 {
                        name hw:0
                        comment 'Physical Device - NVidia CK8S with ALC655 at irq 17'
                }
        }
        pcm {
                alsactl1 {
                        name front:0
                        comment 'Abstract Device - Front Speakers (Duplex)'
                }
                alsactl2 {
                        name plug:front:0
                        comment 'Abstract Device With Conversions - Front Speakers (Duplex)'
                }
                alsactl3 {
                        name 'hw:0,0'
                        comment 'Physical Device - NVidia CK8S (Duplex)'
                }
                alsactl4 {
                        name 'plughw:0,0'
                        comment 'Physical Device With Conversions - NVidia CK8S (Duplex)'
                }
                alsactl5 {
                        name 'hw:0,1'
                        comment 'Physical Device - NVidia CK8S - MIC ADC (Capture)'
                }
                alsactl6 {
                        name 'plughw:0,1'
                        comment 'Physical Device With Conversions - NVidia CK8S - MIC ADC (Capture)'
                }
                alsactl7 {
                        name 'hw:0,2'
                        comment 'Physical Device - NVidia CK8S - IEC958 (Playback)'
                }
                alsactl8 {
                        name 'plughw:0,2'
                        comment 'Physical Device With Conversions - NVidia CK8S - IEC958 (Playback)'
                }
                alsactl9 {
                        name surround40:0
                        comment 'Abstract Device - Front and Rear Speakers (Duplex)'
                }
                alsactl10 {
                        name plug:surround40:0
                        comment 'Abstract Device With Conversions - Front and Rear Speakers (Duplex)'
                }
                alsactl11 {
                        name surround51:0
                        comment 'Abstract Device - Front, Rear, Center and Woofer (Duplex)'
                }
                alsactl12 {
                        name plug:surround51:0
                        comment 'Abstract Device With Conversions - Front, Rear, Center and Woofer (Duplex)'
                }
                alsactl13 {
                        name spdif:0
                        comment 'Abstract Device - S/PDIF (IEC958) Optical or Coaxial Wire (Playback)'
                }
                alsactl14 {
                        name plug:spdif:0
                        comment 'Abstract Device With Conversions - S/PDIF (IEC958) Optical or Coaxial Wire (Playback)'
                }
        }
        rawmidi {
        }
        timer {
                alsactl1 {
                        name 'hw:CLASS=1,SCLASS=0,CARD=-1,DEV=0,SUBDEV=0'
                        comment 'Physical Device - system timer'
                }
        }
        seq {
                alsactl1 {
                        name default
                        comment 'Default Device - Sequencer (Duplex)'
                }
                alsactl2 {
                        name hw
                        comment 'Physical Device - Sequencer (Duplex)'
                }
        }
        [krisbee2008@loca

         
    • Nick Copeland

      Nick Copeland - 2008-11-25

      Hi Kris,

      I was going to suggest this was an issues with the audio buffer size, bristol has a default that might not match the target of the drivers however 256 should be fine. What other apps do work? Do they have issues with buffer size?

      nick

       
    • krisbee

      krisbee - 2008-11-26

      Nick,

      I run everything else fine.. I don't do much audio work lately, and on this partition, but I run some old windows softsynths through wine without issue (VAZ+, SimSynth), however because of the wine porting, I have to keep the latency a bit high 50-80ms, which is a little annoying when you have a live keyboard connected.

      The one thing is that I do not have any midi devices connected (I still have to work on getting the physical interfaces going)... however, that should have nothing to do with it, either.

      I will try to build an earlier build and see where that gets me.  Do you want to see the build output?

       
    • Nick Copeland

      Nick Copeland - 2008-11-26

      Can you try with -count 512 and -count 1024, see what that does?

      The output from the 'make' will not really help much.

      Perhaps it is an issue with ALSA on this soundcard. From the code: the engine could open the audio device, it configured interleaved read/write, it successfully set its sample size (it uses 16 bit to the device and floating point internally), it configured stereo, set the sample rate but then finally failed on the sample count, gave you the error message on period size then it then exits.

      In short, this one call to the library gave a problem, the rest worked. Will have to think about what to do here since I can't even give you diagnostic code as the sequence at this level is pretty clear. I cannot test with your soundcard either but I could try the later ALSA drivers, my system still has its default 1.0.14.

      Regards. Nick

       
      • krisbee

        krisbee - 2008-11-26

        Nick,

        I dropped down a few versions, and ran as you suggested.  No dice... Here is the output:

        [krisbee2008@localhost bristol-0.20.1]$ startBristol -b3 -count 512
        spawning midi thread
        midi sequencer
        open_remote_socket: Address already in use
        socket id 5028
        Could not open control socket, count 0
        No controlling socket available: anticipating MIDI
        Error opening control device, exiting midi thread
        parent going into idle loop
        connected to :0.0
        display is 1280 by 1024 pixels
        Window is w 1280, h 1024, d 24, 0 0 0
        Using DirectColor display
        alloc color by name Blue
        Initialise the hammondB3 link to bristol: 8124658
        parent exiting
        hostname is localhost, bristol
        TCP port: 5028
        Connected to the bristol control socket: 5
        bristolengine already active
        Midi read retry
        Midi read retry
        Midi read retry
        return - no data in buffer
        cleanupBrighton(0)
        Midi read retry
        Midi read retry
        Midi read retry
        return - no data in buffer
        socket closed
        request acked: -1

         
    • Nick Copeland

      Nick Copeland - 2008-11-26

      Hm, if you dropped back from 0.20.9 you would be running into another problem I think - this time you do have zombie bristol engines running maybe? A ps ax would show that - if there are no processes then the other cause of the same message is that Linux has the socket in TIME_WAIT state since it did not exit cleanly. If you try and start bristol when the socket is not available then it complains similarly. There were some small but significant fixes that went into 0.20.9 to help the process exit when it should. There is one other I was going to add - make the engine exit if nobody talks to it within about 10 seconds but that is not done yet.

      Nick.

       
      • krisbee

        krisbee - 2008-11-26

        Well, I just tried that version for the heck of it...  I am back to the latest.

        Here are the OSS errors when I use that as my sound driver:

        [krisbee2008@localhost ~]$ startBristol -oss -b3 -pixmap
        spawning midi thread
        parent going into idle loop
        midi oss
        Opened listening control socket: 5028
        Could not open OSS midi interface
        Error opening midi device hw:0,0, exiting midi thread
        connected to :0.0
        display is 1280 by 1024 pixels
        Window is w 1280, h 1024, d 24, 0 0 0
        Using DirectColor display
        alloc color by name Blue
        Initialise the hammondB3 link to bristol: 8124658
        hostname is localhost, bristol
        TCP port: 5028
        Connected to the bristol control socket: 5
        bristolengine already active
        parent exiting
        return - no data in buffer
        cleanupBrighton(0)
        cleared sigpipe handler
        cleanupBrighton(0)
        midi write error, fd 5, size 1
        midi write error, fd 5, size 12
        midi write error, fd 5, size 1
        return - no data in buffer
        socket closed
        request acked: -1
        [krisbee2008@localhost ~]$    

         
    • krisbee

      krisbee - 2008-11-26

      Oh, and I think you are right about the sound card being the issue... I had Mandriva 2006 installed on another partition, and a much older version of Bristol installed, which I had played with once... well, since upgrading my motherboard and versions, I just haven't used Bristol, so I booted up that partition and tried my old version, and the same basic errors.

      I would prefer not to put another soundcard in here, if you have more ideas for me to check..

       
    • krisbee

      krisbee - 2008-11-27

      And, nope, no zombie bristols when I ps -aux | grep bristol...

       
    • Nick Copeland

      Nick Copeland - 2008-11-27

      I just tried to connect with OSS using the ALSA compatibility and if fails here similarly. I will look into that, it is some wierdness with the default midi device selection. Not sure if this will help you out much but it does kind of need fixing. I take it you use the snd-pcm-oss module on your system rather than oss native drivers? Will have to see if the compatibility code also has issues with the period sizes being requested.

       
    • Nick Copeland

      Nick Copeland - 2008-11-27

      Hi Kris,

      There is a bug in the OSS drivers, you can find details under bug ID 2353017 here on SF, opened to resolve the issue. I am reluctant to say whether this will improve operation on your system with OSS but it is worth testing. There is a file attached to the bug, audioEngine.c that contains a one line fix for merging some flags.

      Now, I had to start bristol as follows:

      startBristol -oss -mididev /dev/sequencer

      The reason is that the default midi device for OSS is /dev/midi, this used to be a symlink to the real midi interface however this symlink is not created by the ALSA compatibility drivers I think. The alternative to giving this option would be 'ln -s /dev/sequencer /dev/midi' but for now I would just give the option.

      As a separate note I also just tested 'startBristol -alsa -b3' and it failed. I will look into that shortly, when -oss or -alsa are specified then a set of parameters are configured specific to the device that override the defaults. Hence, 'startBristol -b3' works with ALSA, I just need to make sure that the -alsa flag does not override the system default audio device.

      Regards,

      Nick.

       
    • krisbee

      krisbee - 2008-11-27

      Well, I get a whole new error with OSS and that switch!  Sorry for being so much trouble, Nick!

      [krisbee2008@localhost ~]$ startBristol -oss -mididev /dev/sequencer -b3
      generate bandwidth limited waveforms(31, 12)
      spawning midi thread
      parent going into idle loop
      Init waiting for midi thread OK status
      Fixing samplerate at 44100
      midi oss
      Opened listening control socket: 5028
      midiOpen: /dev/sequencer(80)
      opened midi device: 0/1
      Got midi thread OK status
      bristol version 0.20.9
      connected to :0.0
      display is 1280 by 1024 pixels
      Window is w 1280, h 1024, d 24, 0 0 0
      Using DirectColor display
      alloc color by name Blue
      Initialise the hammondB3 link to bristol: 813a700
      hostname is localhost, bristol
      TCP port: 5028
      Accepted connection from 0 (3) onto 2 (5)
      Connected to the bristol control socket: 4
      bristolengine already active
      created 32 voices: allocated 32 to synth
      spawning audio thread
      bristolAudioOpen(/dev/audio, 44100, 256, 2020008)
      audioOpen(b7d9e1a0, 0, 1024): /dev/audio
      flags are now 2
      opened audio device with a fragment size of 1024, buffer 0, fd 6/-1
      return - no data in buffer
      cleanupBrighton(0)
      cleared sigpipe handler
      cleanupBrighton(0)
      midi write error, fd 4, size 1
      return - no data in buffer
      socket closed
      request acked: -1
      /usr/local/bin/startBristol: line 321: 25418 Segmentation fault      bristol -rate ${RATE} -count ${COUNT} $*

       
    • Nick Copeland

      Nick Copeland - 2008-11-27

      Hi Kris,

      Don't worry about all the submits on this thread, its interesting and has already shown one major bug that needed fixing, perhaps not the one you wanted admittedly.

      From your first debug with OSS there was this message (I missed it the first time around):

      Could not open OSS midi interface
      Error opening midi device hw:0,0, exiting midi thread

      This causes the engine to exit without even trying the audio interface. The midi device is important here. this looks like an ALSA device which is obviously wrong for OSS drivers. With the -mididev sequencer you tell the engine to listen on the OSS device and this allows the engine to wait for the GUI and then open the audio thread and audio device.

      In the first -oss messages you did not even get to the audio interface. With the option you did get to the audio interface but now it dies due to the bug I needed to fix - the device flags were not being honoured in the library and this causes one of the buffers to remain unallocated giving the problem with the audio device.

      So, the file that is listed in the bug report will fix the flag issue and on my system I then get OSS to work. I will be honest and say that I am not sure your system will work quite so well even with this fix.

      There were a couple of other things - did you try with '-samplerate 48000'? The interface card may have to do samplerate conversion with my default request for 44100 and perhaps that leads to specific demands regarding buffering. Just a thought. Bristol will happily work at 48kHz so it is worth a quick test.

      Regards, nick.

       
    • krisbee

      krisbee - 2008-11-27

      I tried with the samplerate, and it didn't work.

      I should note that I do not have an external midi connection yet (I will get an external sequencer for Christmas!)... but I assumed I could at least get the engine up... my thinking is correct, right?

      I think what I need to do is find my old es 1371 and slap that in and try it.  Might get to it the next day or two and post the results...

       
    • Nick Copeland

      Nick Copeland - 2008-11-27

      You don't need an external keyboard to run and test bristol and most of the time I don't have one connected here. When audio is up and some midi device/interface is at least open then you can play bristol using your qwerty keyboard, the emulators all have a default mapping so when the mouse is in the window it will play notes tracking your keyboard. These events do not go over the midi interface, they are sent using midi messages over a TCP connection between the GUI and engine.

      I would be interested what happens with the 1371, I used to use these for development on my desktop system but most of the work is now done on my laptop.

      Regards, nick.

       
    • Nick Copeland

      Nick Copeland - 2008-11-27

      Hi Kris,

      If you are going to test the es1371 card in the weekend I can build a release before then called 0.20.10 which includes the OSS fix before then. I don't know of a workaround for this issue so the only other alternatives are the file placed in the bug report or another build.

      There was going to be a 0.20.10 somewhere in December, plus the first 0.30 release with a couple more emulators and some improvements on signal levels, filter resonance, etc, but the 0.20 can go out today or tomorrow if you want (it will just have bugfixes, none of the enhancements). The thing about the Nvidia card is that diverse people advise using OSS on these cards. Now they may mean the real OSS drivers since they actually support proprietary interfaces (they are not open sourced Linux drivers). If you do want to test with OSS first, compatability mode or otherwise, let me know.

      Nick.

       
    • krisbee

      krisbee - 2008-11-27

      Okay, with the 1371, we get different errors...

      [krisbee2008@localhost ~]$ startBristol -b3
      generate bandwidth limited waveforms(31, 12)
      spawning midi thread
      Fixing samplerate at 44100
      midi sequencer
      Opened listening control socket: 5028
      midiOpen: bristol(100)
      ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory
      Could not open the MIDI interface.
      Error opening midi device bristol, exiting midi thread
      parent going into idle loop
      bristol version 0.20.9
      connected to :0.0
      display is 1280 by 1024 pixels
      Window is w 1280, h 1024, d 24, 0 0 0
      Using DirectColor display
      alloc color by name Blue
      Initialise the hammondB3 link to bristol: 813a700
      hostname is localhost, bristol
      TCP port: 5028
      connect failed: Connection refused
      connfailed
      opening link to engine: -1
      hostname is localhost, bristol
      TCP port: 5028
      connect failed: Connection refused
      connfailed
      cleanupBrighton(-4)

      [krisbee2008@localhost ~]$ startBristol -b3 -pixmap -alsa
      generate bandwidth limited waveforms(31, 12)
      spawning midi thread
      Fixing samplerate at 44100
      Opened listening control socket: 5028
      midiOpen: hw:0,0(40)
      opened midi device: 0/1
      parent going into idle loop
      Got midi thread OK status
      bristol version 0.20.9
      connected to :0.0
      display is 1280 by 1024 pixels
      Window is w 1280, h 1024, d 24, 0 0 0
      Using DirectColor display
      alloc color by name Blue
      Initialise the hammondB3 link to bristol: 813a700
      hostname is localhost, bristol
      TCP port: 5028
      Accepted connection from 0 (3) onto 2 (4)
      Connected to the bristol control socket: 4
      bristolengine already active
      created 32 voices: allocated 32 to synth
      spawning audio thread
      bristolAudioOpen(plughw:0,0, 44100, 256, 1010008)
      audioOpen(b7d971a0, 0, 1024): plughw:0,0
      opening device plughw:0,0, flags 0000000d
      open playback on plughw:0,0, pre 8
      Could not set playback rate to 44100
      Problem opening audio device plughw:0,0, exiting audio thread
      could not get thread schedule
      Midi read retry (6298)
      Audio Thread status failed: exiting. Is device in use?
      Midi read retry (6298)
      parent exiting
      return - no data in buffer
      cleanupBrighton(0)
      cleared sigpipe handler
      cleanupBrighton(0)
      midi write error, fd 4, size 1
      return - no data in buffer
      socket closed
      request acked: -1

      And with OSS:

      [krisbee2008@localhost ~]$ startBristol -b3 -oss -pixmap
      generate bandwidth limited waveforms(31, 12)
      spawning midi thread
      Fixing samplerate at 44100
      midi oss
      Opened listening control socket: 5028
      midiOpen: hw:0,0(80)
      Could not open OSS midi interface
      Error opening midi device hw:0,0, exiting midi thread
      parent going into idle loop
      bristol version 0.20.9
      connected to :0.0
      display is 1280 by 1024 pixels
      Window is w 1280, h 1024, d 24, 0 0 0
      Using DirectColor display
      alloc color by name Blue
      Initialise the hammondB3 link to bristol: 813a700
      hostname is localhost, bristol
      TCP port: 5028
      connect failed: Connection refused
      connfailed
      opening link to engine: -1
      hostname is localhost, bristol
      TCP port: 5028
      connect failed: Connection refused
      connfailed
      cleanupBrighton(-4)
      [krisbee2008@localhost ~]$                    

       
    • Nick Copeland

      Nick Copeland - 2008-11-28

      This first one is the most basic and should work, this fails for you because it
      cannot get a MIDI interface. Does not even attempt any audio. GUI fails since
      the engine is not active. Why don't you have the seq interface? That is not
      really such a big problem, your next attempt:

      This is the same except -alsa is specified. This does get the MIDI interface
      but fails on audio with a slightly different error: cannot set the sample rate.
      The original post had a problem with the buffer sizes. The midi thread (and
      engine) then exit due to failure of the audio thread. This is a bigger problem
      since it is again pretty arbitrary, the audio device is available and can be
      opened however parameter settings which are required to ensure the audio used
      by bristol matches the one requested from the audio device match.

      Then with OSS:
      This faults on the MIDI interface not being available again. The MIDI failure
      needs to have the '-mididev sequencer' option added. It can then open MIDI but
      this will then fail due to a bug in the audio drivers - flags are not converged
      correcly with OSS, something that is fixed in 0.20.10 and above.

      Saying that this one little bug is fixed though will not resolve all your
      issues, it will just get you a little further along with the OSS interface
      which is not what you want.

      I have never seen such an arbitrary set of faults before, each time things look
      a little different. What is this system? The only prior mention was of an old
      release with Mandriva 2006 but nothing about this system. Is it Linux native
      or virtualised? Is it a 64 bit system since I know that can give some pretty
      wierd issues due to type mismatches and I would not call bristol 64 bit clean
      yet.

      Regards, Nick

       
1 2 > >> (Page 1 of 2)

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

Sign up for the SourceForge newsletter:





No, thanks