Some users have experienced issues playing video or audio files in BITTSy - either failing to play, or with problems like stuttering, stalling, freezing, or missing audio channels. Here are steps to take to resolve these issues.
Check our recommendations for visual and audio stimuli See this page.
Ensure your files are compatible with Windows 10 and playable with existing codecs Particularly if your stimuli were made on a Mac or originally used for studies on a Mac, your stimuli may be working poorly with BITTSy simply because they work poorly with Windows. Test this by opening your files in a Windows-native default application such as Windows Media Player and checking whether they play correctly. If they don't, you'll either need to convert to a new format or install a new codec to interpret the file.
Try re-converting your files Creating video/audio files in a compatible format for your computer requires using compatible options for... - video container format (e.g. MP4, WMV) - audio container format (e.g. WAV, AAC) - video codec (e.g. wmv1/wmv2, msmpeg4) - audio codec (e.g. adpcm_ima_wav). Container formats are what you are used to seeing - they're file extensions - and they're easy to directly specify in conversion programs, and see in your files by viewing their file properties. We recommend WMV and MP4 as video container formats, and MP3 and WAV as audio formats, although others may also work well. Container formats that are Mac-specific, such as AIFF for audio and MOV for video (Apple recently ended support of Quicktime for Windows, which used to help these play!) should always be avoided. Sometimes even with the recommended container formats, you can have a video that isn't compatible with your system and may experience playback issues, and this is generally due to incompatible codecs. However, unlike with container formats, it is often difficult to verify which video and audio codecs are being used (within conversion software) or were used (for an existing file). If you can create/convert your video files on the same computer that you use to run BITTSy, this is generally a good way to ensure you're always using codecs that are compatible and available on your system. We recommend FFmpeg as a free video conversion program that gives you a lot of control over the audio/video settings and encoding.
Try switching your video rendering settings Under the advanced settings menu within the main BITTSy user interface, you can select whether to use hardware rendering or software rendering for playing videos. One of these may result in better performance on your system. See this page for more information.
Try installing additional video codecs on your computer Finally, it's possible that your videos could play better with different codecs, or that there are some problems with the codecs that came preloaded on your computer. If you try downloading and installing a codec pack, be sure to ask tech support staff at your institution for guidance and recommendations - many links out there are actually malware! The K-Lite standard codec pack (downloaded from here) was helpful for some users.
Got a question or issue? Check our F.A.Q.!
We are also adding longer descriptions and solutions for issues that can come up with setting up your system to run experiments in BITTSy, whether or not they are issues with BITTSy itself. Check the topics below if you are having trouble with these aspects of setting up your system, or contact us if there is something our team can help you look into.
Check that you're opening the correct application file. There are a lot of supporting files that have similar names or look like something you should open, but aren't the main BITTSy program, so this can be confusing! Check what you're trying to open against the screenshots shown here. If you made a shortcut earlier, check that it's correctly referencing this main application file.
Give Windows Defender permission to allow BITTSy to run. If you aren't able to double-click on the BITTSy program to run it, try right-clicking and selecting Open. If you get a blue pop-up trying to warn you that it was downloaded from the internet, click More Info then Run Anyway.
These are warnings about your computer missing a driver for lights or there not being a DMX controller for the lights recognized by your computer. If you aren't using lights, you can ignore these completely, and just click through them to launch BITTSy! If you are using lights, these are critical errors that need to be addressed before trying to validate your protocol - which is why they're checked upon launch. Check that you downloaded the appropriate drivers and firmware (step #6) for your USB-DMX interface box, and that it is connected to your computer.
This is intended, as a foolproof way of preventing uncaught validation errors or execution errors from one protocol from ever affecting subsequent runs. Close out of BITTSy and open it again so that you can select a new protocol, or load and run the same one again.
BITTSy will display this error whenever your system doesn't have enough displays active, so make sure that your system has the external monitors configured and recognized properly. Check that your display settings in Windows are set to Extend Mode, and all your additional displays are powered on before opening BITTSy. (See this section on display ID numbers for more background on how BITTSy uses displays.)
Protocols that do not require the use of displays should not contain the DISPLAYS ARE starting definition at all. This prevents you from having to turn on unnecessary equipment for every run just so that the protocol avoids this validation error.
There are several possibilities.
Make sure that you have the correct and full file path specified in your protocol for each of the files, and that all of your files are present in the desired folder.
Verify that there are no typos, either in your protocol or in the names of the files themselves.
Make sure you're using backslashes (\), not forward slashes (/) in your file paths.
If you typed up your protocol file on a Mac, there could be an encoding issue that causes important characters for parsing protocols, particularly quotation marks, to be read differently on a PC. There are two types of quotation marks, straight and curved. When you type a quotation mark in TextEdit on a Mac, you get curved ones, but BITTSy expects the default for a PC, which is straight quotation marks. Try deleting your quotation marks and retyping them on your PC in Notepad or another plain text editor. If they look different, this was likely an issue for you. (Use find+replace to fix all of them!)
All the text boxes on the user interface have their contents saved to the log file immediately when you start running a protocol file. This ensures that this important information for identifying the log file is always present, in case an experiment unexpectedly crashes or access to the log file is lost. Once you click the Run button, they are locked from editing, to help make it clear that no further information from there can be saved. After the session, experimenter notes or comments on how the session went can be added manually to the log file by opening it in a text editor, or you can use other paper or electronic documents such as a run book.
If you choose to manually edit log files, be sure that they are always opened after the experiment has stopped completely, as demonstrated by a pop-up in BITTSy, indicating successful execution or an early termination of the experiment after pressing the Escape key. This ensures that BITTSy has completed writing information to the log file, and that there are no conflicts between your accessing the file to make edits and BITTSy finishing logging events from the experiment.
When you open an instance of BITTSy, it checks for the device that controls the lights, and if it's available, takes control of it. Once a program controls this device, that program must signal to give it up before another program can gain control. Since BITTSy is likely to be the only program on your computer you're using with your DMX controller for the lights, the issue is when there are two instances of BITTSy open at once - only one of them can be controlling the lights at any given time.
In BITTSy, the signal to give up control of the lights comes when:
You close out of the BITTSy window without having started to run a protocol
The experiment executes successfully (end of the protocol file is reached)
BITTSy encounters an execution error and interrupts the run with an error message
You press the Escape key to end the study early
If you are already running a protocol, it does not come when you click the red X to close the main BITTSy window, or right-click and close BITTSy from the task bar. These only close the user interface, and don't fully stop background processes such as the control of the lights. So if you close BITTSy improperly in the middle of an experiment, then reopen BITTSy to run a new protocol, you may get strange behavior in regards to using the lights: they may respond to keypresses as if you are still running the previous experiment, or they might not respond at all.
You can fix this by fully stopping the previously-running instance of BITTSy that is still controlling the lights. Press Ctrl+Alt+Delete and go into Task Manager, select any instance of BITTSy that appears, and End Task.
Ending an experiment before closing the main BITTSy window is important both for avoiding this problem and for ensuring that log files are complete and not at risk of being corrupted. If you need to close out of BITTSy before the end of an experiment, always press the escape key first, and wait for the pop-up that execution has been stopped!
Simply open BITTSy again, and the lights should all turn off. (If they don't, see question above - your previous run may not have ended fully.)
Submit a bug report/request for help, and a member of our team will contact you!
Check the topics below if you are having trouble with these aspects of setting up your system, or if there is something our team can help you look into!
to label them appropriately for BITTSy is covered earlier in this manual, but this section explains the assigning of display ID numbers and side labels in more depth, and what kinds of changes to your system can affect your DISPLAYS starting definition.
When you have multiple displays connected (and configured to extend rather than duplicate each other), your operating system will assign them each an ID number. In Windows 10, you can see what the system is assigning to which screen by going into the Display Settings (right click on the desktop and select this option), then clicking Identify, as shown on the image below.
This will cause number labels to appear temporarily in the corner of each of your connected displays. If you would like to change which number is associated with which monitor, you can click and drag the numbered boxes that appear above the Identify button. However, be careful to verify that your changes "stick" whenever your computer is restarted, or your displays are turned off and back on.
Except for when you, the user, specify an order (by clicking and dragging numbers in the Display Settings as mentioned above), Windows will assign display IDs solely by the port where the monitor is plugged into your computer. Windows doesn't "know" that you've arranged your monitors on one side or another of your desk or room - it only knows that there's a cable coming out of that particular display output jack, and a display plugged in on the other end.
This has several important implications for using displays for experiments in BITTSy.
BITTSy relies on how the operating system numbers monitors, and if the operating system switches the display IDs for any reason, BITTSy will need to be given an updated DISPLAYS definition to preserve the matching of physical devices to their locations.
For example, let's say the experimenter's monitor (where the BITTSy window will be, and no stimuli) had ID 1, a right-side monitor has ID 2, and a left-side monitor has ID 3. BITTSy will take the lowest ID that is not the experimenter's monitor, and assign it the first side name in the DISPLAYS ARE definition. This means that our right-side monitor (#2) will be chosen first, then the left-side one (#3), so the DISPLAYS ARE statement should label those sides in that order.
The goal of the setup protocol is to help you identify the display IDs of your monitors, and label them with the appropriate side names so that BITTSy will display images/videos to the intended location whenever you use an action statement. But you can also use Windows to show the display IDs, as described on this page; your DISPLAYS ARE statement should simply list the side names, in order, that correspond to those ID numbers.
The operating system's display ID assignment depends on where the monitor is plugged into your computer. Therefore, anytime that you unplug and replug a display cable, you should run the setup protocol to verify that your system is still assigning the same IDs to the same devices, and the DISPLAYS starting definition is still the correct order to match where your displays are positioned in your room.
Because the operating system doesn't tell BITTSy anything about where monitors are located, we have to do that within the protocol file (that is, we need a !)
Whenever you , BITTSy will fetch the display ID numbers from your operating system, and will match them, in order, to the side names that appear in that protocol's DISPLAYS starting definition.
If you experience monitors swapping IDs for any reason other than unplugging and replugging into your computer, Some users have experienced this issue in Windows 10, and others not at all. There may be a numbering that is more stable on your system than the default, which you can check by reordering your monitors in Display Settings (or swapping where monitors are plugged in) and checking that the display IDs assigned stay consistent across restarting your computer. Some TVs connected via HDMI appear to take priority over other connected monitors; you can try manually setting them to be a lower ID number. If your computer has an upgraded graphics card, it may matter if you have some displays connected directly to the motherboard/on-board graphics card and others connected to ports that are located on your installed graphics card. It also may matter whether your displays are all powered on before turning on your computer, or whether you're turning them on after the computer has started up.
BITTSy can send an audio file to play over just one speaker out of the available array for your system. How it actually does this is to send file information to the desired speaker to play at full volume, and silence of the same length to play at the other speakers. (The silence does not block those speakers from playing another audio file from a subsequent protocol line; the two will be played simultaneously, and since one has no audio information and is completely silent, it does not affect the second file's playback.)
It is possible to experience an effect where audio that is sent to only one speaker is also heard at a lower volume on another speaker - an audio channel crossover effect. This is not caused by BITTSy, but could be a result of 1) a cable/audio jack issue, 2) a sound card driver "audio enhancement" effect, or 3) an issue with your sound card.
If you get a warning about Waves MaxxAudio whenever you open BITTSy, #2 should be fixed first. Skip to the sound card driver section below.
Before you start, make sure the audio file you're using is in one of our suggested file formats. When playing file formats such as .aiff (native to Mac computers rather than Windows), some users find that they can play the file, but it does not play correctly with respect to channel separation, and converting to a .wav format resolves the issue. See this page for more info.
The first possibility is the easiest to check. Unplug the cable that runs from the 3.5mm audio jack on your computer to your speakers and plug in a pair of headphones (which you know work!) instead. Wired earbuds work especially well because you can put in just one at a time to check that the channel that is not supposed to be playing audio is in fact silent.
It's best to try headphones that match the jack type on the computer, either stereo audio (3 metal sections separated by 2 rings) or stereo audio plus microphone input (four sections separated by 3 rings). If your computer has a separate dedicated microphone jack nearby, the audio output jack will be just stereo audio.
Test your audio with these headphones. You can do this easily with a test audio file that you know to be only in one channel with silence in the other, or where the two channels are completely different, and playing it in Windows Media Player (BITTSy relies on the same codecs and calls as Windows Media Player and playback should be the same between the two), but you could also run a simple BITTSy protocol that plays a file to just one side, waits for a keypress, then plays to the other.
If the headphones play audio as intended: You may need to replace the audio cable that runs to your speakers. It may have been damaged, or the sections on its cable may be misaligned with respect to your computer's audio jack. You can test the latter possibility in the same manner described below for headphones. These cables are cheap, so it is worth buying a couple more from different manufacturers and returning whatever doesn't work. If nothing seems to align with your computer, there may have been a manufacturing issue; check if it is under warranty and proceed from there.
If the headphones have the same crossover issue: It's less likely that the issue is with the speaker audio cable itself, but there could be a problem with the audio jack on your computer. Different manufacturers can place the sections and buffer rings (as you see on the diagram above) in slightly different places, and a misalignment between cable and jack can mean that information the computer is sending to one channel can be also received on the very edge of another. This will cause a very faint and often static-sounding version of the audio to be played on the other channel, while a fuller-sounding version plays to the correct one. Try unplugging your headphones slowly and very slightly as you listen, and see if the crossover issue resolves at any point. If this is your issue, there will be a place where you can leave it and both left-only and right-only audio will play cleanly, without crossover and at full volume.
If it doesn't seem to be a jack alignment issue: Check your sound card driver next (below).
Sound card drivers take audio information (such as audio files that BITTSy opens) and format that information into the final signal that is sent via your audio jack and cable to play through your speakers. Any functional sound driver will correctly take in all the specifics of the audio file, and take information from the software that requested the file about how to play it - but importantly, sound drivers can use their own settings within the formatting step to change the final output from being played exactly how the file and requesting program specified.
These are audio "enhancements" and may include rebalancing across frequency ranges (such as a bass boost), balancing perceived loudness across files (rather than playing them with their encoded average intensities), and introducing slight audio channel crossover for a more "natural" sound. These can be nice for listening to music, but for experiments, it is extremely important that stimuli are played with fidelity, exactly as they were designed. And since these audio enhancements are applied at the end, right before the signal is sent to the speakers, BITTSy can't do anything about it - its request to play the file to only one channel, with complete silence on the other, is overridden and remixed to have crossover.
First, ensure that audio enhancements are turned off within Windows 10. See instructions here.
Now that those are disabled, you may still have more places where these kinds of enhancements are turned on, or you may have a sound driver that doesn't have options to turn them off. Check what sound driver(s) is/are active on your computer by opening Device Manager (type it in your search bar) and expanding the "Sound, video and game controllers" menu. There may be several listed, from companies such as Intel and Realtek.
Search for each of these on your computer and see if you have a program installed along with that driver that serves as a control panel for it. In this program, look for where to turn off audio enhancements (search online for support for your specific driver if you need to.)
Waves MaxxAudio is a type of Realtek driver that ships with some Dell computers, and applies a lot of audio "enhancements" but (at present) has no options to turn them off. If you have Waves MaxxAudio on your computer, your only recourse is to uninstall it and revert to a generic Windows sound driver. Because Waves MaxxAudio causes so many problems, BITTSy versions 1.32 and later will specifically check to see if Waves MaxxAudio is installed and display a warning if it detects it on your system, every time you open BITTSy.
The warning dialog contains a link with steps to fix the issue and install the generic sound driver. Once you restart your computer, check that Waves MaxxAudio is really gone (open BITTSy and it will check for you!) Your computer will scan for new drivers on restart, and may find an older version of Waves MaxxAudio that wasn't removed during the uninstall, or could download a new copy of Waves MaxxAudio via Windows Update whenever an updated driver is made available. If this happens, you'll need to repeat the process again until it is completely gone.
Under the Advanced Settings menu in BITTSy, there are also options to pause or disable Waves MaxxAudio. These can be used if you are unable to uninstall it. However, you will need to re-select to disable Waves whenever you download and start using a new version of BITTSy.
It is possible that there are other sound drivers out there that are just as bad as Waves MaxxAudio... this is just the one that several of our beta testing labs encountered. If you have a different driver but are having similar audio problems, you can still use our instructions to disable it and replace it with a generic driver. (If that fixes the issue, let us know what your driver was so we can add it to the bad list!)
A final possibility is that there could be a defect in your sound card that is causing it to have electrical crossover between audio channels. This is rare, because the manufacturing standards for channel crossover at normal playing volumes are set well below human hearing thresholds - there would need to be a major issue to make them even barely audible. But if you've eliminated other possibilities, it may be best to try to replace your sound card. Check warranties, whether your sound card is the standard one for your computer model, and what other sound cards are compatible.
