Från en vanlig MP3-ström till Relay 7 Kontrollcenter.

Hur jag tänkte då

2020 fanns ingen anledning att bygga ett stort system. Jag behövde först bevisa att idén hade ett värde för mig. Det gjorde att jag höll arkitekturen nästan löjligt enkel. Ju färre delar som fanns, desto lättare var det att förstå varför strömmen dog när den dog.

Jag fick samtidigt den första smaken av ett problem som skulle följa projektet i sex år: en internetradio är en kedja av realtid och halv-realtid. Filen kan finnas på disk men ändå komma för sent. Nätet kan vara snabbt men ändå få ett kort avbrott. Klienten kan ha buffert men ändå tappa om upstream står still för länge. Redan här lärde jag mig att felsökning måste göras från källa till lyssnare, inte från den komponent jag råkar misstänka först.

Jag testade därför mycket genom att medvetet stoppa och starta delar. Vad händer när källan försvinner? Kommer strömmen tillbaka? Vad ser klienten? Måste någon manuellt trycka på play igen? Sådana tester blev grunden för det jag idag kallar recovery-behaviour.

De första nätterna med strömmen

Det första jag fick lära mig var att en MP3-ström kan fungera perfekt medan jag tittar på den och ändå bete sig helt annorlunda efter några timmar. Jag kunde starta en spelare, höra musik, byta låt och tro att allt var klart. Sedan kunde jag komma tillbaka senare och upptäcka att metadata hade frusit, att källan hade tappat kopplingen eller att någon del inte hade återanslutit efter ett kort nätproblem.

Jag började därför testa på ett helt annat sätt. I stället för att bara fråga “spelar det?” började jag medvetet skapa fel. Jag stoppade källan, startade om den, bröt anslutningen och såg vad som kom tillbaka av sig självt. Jag testade vad som händer om en låtfil saknas, om nästa fil har ett annat tekniskt format och om en klient ansluter mitt i ett byte. Det gav mig tidigt en respekt för recovery som jag fortfarande använder idag.

Det var också här jag började förstå värdet av att inte låta en enda process vara allt. Om samma process väljer låt, kodar ljud, håller streamen och serverar metadata blir ett litet fel ett stort fel. Jag hade inte orden “separation of concerns” i huvudet varje gång, men jag började intuitivt vilja bryta isär saker.

if source_disappears:
      keep_service_alive()
      retry_source()
  
  if metadata_breaks:
      audio_must_continue()
  
  if one_component_restarts:
      avoid_restarting_everything()

Det här är viktigt eftersom dagens Relay Seven ser väldigt avancerat ut jämfört med 2020, men själva grundkravet är fortfarande identiskt: musikströmmen är den sista saken som ska ge upp.

Det tråkiga jobbet som senare blev guld

Jag började föra enklare anteckningar om när något stannade och vad som hänt precis innan. Det var inte avancerad observability, men det lärde mig att tidsstämplar är värdefulla. “Det dog någon gång i natt” hjälper nästan inte alls. “Källan tappade kontakt 02:14:07 och försökte återansluta 02:14:12” går att arbeta med.

Jag började också skilja på process up och service healthy. En process kan leva men vara oanvändbar. Den kan ha en öppen port men inte leverera ljud. Den idén återkommer idag i Westin-AI och Kontrollcenter där health inte bara betyder att processen finns.

Jag byggde mina första mentala health checks innan jag hade riktiga health endpoints

I början bestod kontrollen ofta av ganska manuella frågor. Hör jag ljud? Byter låtnamnet? Går det att ansluta igen efter att spelaren stoppats? Fortsätter servern efter en omstart? Det var enkelt, men det lärde mig att “processen kör” är ett dåligt mått på om en radiotjänst är frisk.

En process kan leva men sitta fast. En port kan svara men skicka gammal data. En ljudkälla kan vara ansluten utan att faktiskt mata frames. Därför började jag tänka i flera nivåer av hälsa: process, anslutning, dataflöde och faktisk output.

Den tanken har senare blivit mycket konkret i tjänsterna. Westin-AI behöver inte bara säga att processen lever; Kontrollcenter behöver veta om modellen är redo att rendera. Now Playing behöver inte bara svara HTTP; svaret ska ha färsk metadata. Broadcast kan vara uppe, men om ljudkön inte rör sig är något ändå fel.

Jag började också inse att loggar måste berätta mer än “error”. Ett fel som bara säger att något gick snett tvingar mig att återskapa problemet. Ett fel som säger vilken del, när, med vilket state och vilken fallback som valdes blir dokumentation i realtid.

Metadata blev mitt första API-problem

Det var lockande att låta webben läsa rå streammetadata direkt. Jag gjorde sådana försök, men problemet blev snart att varje klient behövde förstå specialfallen. Jag ville inte ha samma regex i webben, mobilen och en framtida adminpanel.

Jag började därför tänka i ett canonical now-playing object. Det behöver inte spegla exakt hur upstream skriver metadata. Det ska spegla hur Relay Seven definierar “en aktuell låt”. När den tanken satt blev API-lagret ett naturligt hem för fler saker senare.

Historiken blev det första stället där “rådata” och “sanning för lyssnaren” skildes åt

När jag började visa historik märkte jag snabbt att rå metadata inte är samma sak som en publik händelselogg. Ett internt stations-ID kan vara relevant för driften men ointressant i historiken. Samma låt kan rapporteras flera gånger när metadata uppdateras. En tom artist eller titel ska inte skapa en post bara för att upstream skickade något.

Jag började lägga in små filter ett efter ett. Först ignorera tomma poster. Sedan ignorera kända interna etiketter. Sedan deduplicera samma artist/titel inom kort tid. Sedan hålla ett begränsat antal poster så sidan inte växer okontrollerat.

Det här blev så småningom en viktig designprincip för alla publika API:er: jag vill skicka domändata, inte implementationens rådata. Om Broadcast internt kallar något “voice_queue” behöver appen inte veta det. Om ett stations-ID spelas ska historiken kunna behandla det enligt publik policy utan att klienten känner till hur Broadcast klassificerar filer.

event = normalize(rawMetadata)
  
  if event.is_internal:
      skip()
  
  if same_as_last_public_track(event):
      skip()
  
  history.prepend(event)
  history = history.slice(0, limit)

Det här gjorde senare flytten till flera klienter betydligt lättare.

Det första schemat såg enklare ut än problemet var

Jag började med typiska tidsregler: den här listan gäller här, den där listan gäller där. Men låtar känner inte till klockan. En sexminuterslåt som startar 17:58 kan lätt sabotera ett program som ska börja 18:00 om ingenting planerar framåt.

Först försökte jag lösa det med hårda bryt. Sedan med mer luft runt blockgränser. Sedan med att förbjuda vissa låtar nära gränsen. Varje variant lärde mig en del, och senare kunde jag kombinera idéerna i Show Engine i stället för att lägga fler specialfall i playlisten.

Schemaexperimenten skapade mina första “regler ovanpå regler”

När jag började tidsstyra innehåll dök problem upp som inte fanns i den enkla MP3-perioden. En lista kunde vara rätt för klockslaget men fel för övergången. En jingle kunde vara tillåten enligt sitt intervall men hamna precis före ett planerat programbyte. En låt kunde vara helt rätt musikaliskt men för lång för det tidsfönster som återstod.

Jag löste först sådant lokalt. Ett extra villkor här, en spärr där. Det fungerar väldigt snabbt men bygger snart ett system där ingen enskild regel förklarar slutresultatet. Det var första gången jag fick känna kostnaden av specialfall.

Den erfarenheten är en stor anledning till att dagens kod försöker centralisera vissa typer av beslut. Showgränser ägs av Show Engine. Talk-kollisioner ägs av Talk Scheduler. Musikrecency ägs av Picker. När en ny regel ska in försöker jag först avgöra vilket av de lagren som faktiskt borde äga den.

Det är en ganska stor utveckling från de tidiga åren: då var fokus att få nästa beteende att fungera. Nu är fokus ofta att få beteendet att fungera utan att nästa beteende måste känna till specialfallet.

Live visade varför ägarskap måste vara explicit

När live och automation båda kan producera ljud måste någon veta vem som äger utgången. Jag hade perioder där det räckte att livekällan “fanns” för att automationen skulle bete sig annorlunda, men det är inte samma sak som att live faktiskt sänder.

Det ledde till tydligare state: connected, armed, active och fallback är olika saker. Den typen av tillståndsmaskin låter överdriven tills en livekälla dör mitt i sändning och automationen ska veta om den får ta över direkt.

Livevägen lärde mig skillnaden mellan närvaro och ägarskap

En livekälla kan vara ansluten utan att vara on air. Den kan vara redo men tyst. Den kan försvinna mitt i en låt. Tidiga försök där “ansluten” automatiskt betydde “live äger sändningen” skapade därför konstiga lägen.

Jag började tänka i tillstånd i stället: live kan vara frånkopplad, ansluten, armed eller aktiv. Automation behöver veta när den ska stå tillbaka och när den får ta över igen. Det är en annan typ av state än “vilken låt spelar”.

Det gav också en viktig säkerhetsprincip: live ska kunna fallera utan att göra hela streamen svart. Om den aktiva källan försvinner måste det finnas en definierad väg tillbaka till automation. Jag föredrar ett oväntat men spelande reservläge framför total tystnad.

Den här idén påverkar idag även AI-segment. Ett optional talk kan försvinna helt utan att musiken behöver påverkas. Den generativa kedjan får aldrig bli enda vägen till ljud.

Brandväggen blev också felsökningsverktyg

När jag hade flera interna tjänster började jag använda brandvägg och gateway för att göra gränserna synliga. Om bara Gateway får exponeras publikt kan jag snabbt avgöra om ett fel ligger före eller efter den.

Jag testade också bandbreddsregler och separata nätprofiler. Det lärde mig att en radioanslutning inte beter sig som vanlig webbladdning. En långlivad stream kan påverkas på helt andra sätt av shaping och timeouts. Därför försöker jag numera separera regler för interaktiv webbtrafik från regler för långlivade ljudflöden.

Jag fick lära mig att långlivade anslutningar inte är vanlig webbtrafik

När jag började göra mer med brandvägg, shaping och separata nät såg jag att en stream beter sig annorlunda än en vanlig sida. En webbsida gör korta anrop och kan ofta bara försöka igen. En radioström vill hålla samma flöde levande länge.

Det betyder att aggressiva timeouts, konstiga NAT-beteenden eller felaktig bandbreddspolicy kan ge små avbrott som aldrig syns när jag bara testar en API-request. Jag fick därför börja testa nätförändringar med riktig lyssning över tid.

Jag började även hålla radiomaskinerna separerade från annan trafik där det var praktiskt. Poängen är inte att en MP3-ström kräver enorm bandbredd. Poängen är förutsägbarhet. Om en annan enhet råkar starta en stor överföring ska inte radiokedjan behöva märka det.

Brandväggen blev på så sätt både skydd, trafikpolis och felsökningsgräns.

Namnvalet påverkade koden mer än väntat

När Relay Seven blev det fasta namnet började stationsidentiteten dyka upp överallt: metadata, titelrader, jinglar, apptexter, API-output och promptregler. Det gjorde mig uppmärksam på hur farligt det är att hårdkoda namn i tjugo filer.

Jag började därför flytta stationsnamn och liknande identitet till gemensamma settings. Samma princip används för location, showname och persona. Branding är data när det går, inte utspridd kod.

Programnamn blev mer än branding

När jag började skapa namn som Rewind märkte jag att ett programnamn snabbt drar med sig tekniska krav. Om Rewind är ett riktigt program vill jag kunna säga när det går, vem som leder det, vilket musikområde det har och hur promotionen ska låta.

Det betyder att showen behöver en identitet som går att referera till i schema, prompt, webb och app. Jag ville inte att varje yta skulle bära en egen textsträng med “fredag 18–21”. Den typen av duplicering blir alltid fel förr eller senare.

Det här blev början på mer strukturerad showdata. Namn, tidsfönster, host, mood och policy kan läsas av flera lager. När en show byter tid ska jag i princip ändra sanningen på ett ställe.

Webben blev också en driftpanel

När jag ändå hade realtidsdata började jag använda webben för att upptäcka fel. Om now-playing inte uppdateras men ljudet hörs vet jag att metadata/API-lagret är misstänkt. Om appen ser nytt men webben gammalt är klientcache mer sannolik.

Det här är en anledning till att jag gillar små statusytor. En bra UI-indikator kan vara minst lika användbar som en loggrad när jag snabbt ska förstå vilket lager som lever.

Jag började bygga UI efter driftbehov och inte bara utseende

Webben var först till för lyssnaren, men jag märkte snabbt hur värdefull den var för mig själv. Om “nu spelas” stannar på en gammal låt medan ljudet fortsätter vet jag direkt att audio och metadata har skiljt sig åt. Om historiken uppdateras men omslaget inte gör det kan felet ligga ännu längre ut i kedjan.

Det gjorde att jag började uppskatta små visuella signaler. En statuspunkt, senaste uppdateringstid och ett tydligt fallbackläge kan spara mycket mer tid än en stor logg när jag först ska hitta rätt del.

Jag ville samtidigt inte förvandla publikspelaren till en teknisk dashboard. Därför växte tanken på en separat kontrollvy fram: publiken får det som är relevant för lyssning, jag får de diagnostiska detaljerna i Kontrollcenter.

Uttalsproblemen blev en försmak av hela AI-arkitekturen

Jingleförsöken lärde mig att text och ljud inte är samma sak. En text kan vara perfekt skriven och ändå produceras på ett sätt som låter fel. Det är därför jag senare undvek att blanda voice style, uttalsknep och faktainnehåll i samma lager.

Jag vill att Kontrollcenter bestämmer vilket innehåll som är korrekt. Westin-AI bestämmer hur det ska produceras enligt en styleprofil. Om ett särskilt ord kräver en uttalsform ska den hanteras som uttalsdata, inte som en kreativ omskrivning av hela meningen.

Den separationen gör det också lättare att byta teknik under röstmotorn utan att ändra showlogiken.

Varför den första stora installationen ändå var värdefull

Det hade varit lätt att i efterhand kalla den här perioden en omväg. Det vore fel. Den färdiga plattformen gav mig en referens för vad bra radioadministration behöver innehålla. Jag kunde se hur bibliotek, schema och streamkontroll hänger ihop utan att först skriva allt själv.

Det jag senare byggde eget är därför inte byggt ur tomma luften. Jag tog med mig funktionerna jag faktiskt använde och slutade bära runt på funktionerna som inte passade Relay Seven.

Den första stora plattformen gav mig både fart och teknisk skuld

Jag fick snabbt ett administrationsgränssnitt, schema och bibliotek. Det var exakt vad jag behövde då. Samtidigt började egna behov byggas utanför systemet. För varje specialfunktion ökade avståndet mellan “standardinstallationen” och den station jag faktiskt körde.

Det blev små scripts, extra proxyregler, egna endpoints och manuella ändringar. Inget av det var katastrof i sig, men efter ett tag blev det svårt att svara på en enkel fråga: vilken del är egentligen källan till sanningen?

Det var en viktig anledning till nästa generations tänk. Jag ville inte längre ha en huvudprodukt och tjugo saker som korrigerar den. Jag ville ha tydliga egna tjänster med ansvar jag själv definierar.

Samtidigt försökte jag behålla de bra idéerna: tydliga spellistor, schema som går att administrera och robust streamdrift. Jag kastade alltså inte erfarenheten när jag bytte arkitektur.

Jag ändrade en sak i taget efter det

Routingfelet lärde mig en disciplin som jag försöker följa hårdare nu: ändra inte backend, gateway och DNS i samma felsökningssteg. Om jag gör tre förändringar och problemet försvinner vet jag inte vilken som löste det.

Numera försöker jag få ett bevis per lager. Curl-liknande probe mot intern tjänst. Samma payload via Gateway. Sedan extern väg. Först därefter klienten. Det är långsammare de första fem minuterna och mycket snabbare efter en timme.

Jag slutade felsöka med “ändra tills det funkar”

Fel routing var ett bra exempel på varför metod spelar roll. Hade jag samtidigt ändrat streamkonfiguration, gateway och DNS hade problemet kanske försvunnit men jag hade inte vetat varför.

Efter det försöker jag arbeta med bevis. Först intern tjänst direkt. Sedan samma tjänst via Gateway. Sedan publik adress. Sedan klienten. Om ett steg fungerar och nästa inte gör det ligger felet mellan dem.

backend_ok = probe(internal_service)
  gateway_ok = probe(public_route_locally)
  dns_ok     = resolve(public_name)
  tls_ok     = handshake(public_name)
  client_ok  = load(real_client)

Den typen av disciplin har blivit ännu viktigare ju fler tjänster jag byggt.

Den fristående broadcastgenerationen gav mig kontroll men kostade mer eget ansvar

När jag började äga fler konfigurationsfiler själv försvann vissa bekvämligheter. Jag fick själv se till att tjänsten startar efter reboot, att kataloger finns, att rätt användare kommer åt filerna och att fel inte lämnar en halvskriven config.

Det var här atomiska filskrivningar och tydliga servicegränser började bli intressanta. Hellre skriv tempfil och rename än låt en läsare se en halv JSON-fil. Små driftmönster som det har senare blivit standard i state-modulerna.

Mer frihet betydde också fler saker jag själv måste ta ansvar för

När jag började köra mer fristående tjänster försvann den färdiga plattformens skyddsräcken. Nu behövde jag själv hålla koll på service-start, katalogrättigheter, loggning, konfigurationsbackup och hur en halvskriven statefil undviks.

Det var här jag började använda atomiska skrivningar för state. I stället för att skriva direkt till slutfilen skriver jag till en tillfällig fil och byter namn först när hela innehållet är klart. Om processen dör mitt under skrivning ska nästa start inte mötas av halv JSON.

Det låter långt från radio, men det är precis den typen av tråkig teknik som gör att en show inte glömmer sitt state bara för att en process startades om vid fel ögonblick.

Ljudtesterna var mycket mer lyssning än mätning

Jag kunde mäta nivå och bitrate, men frågan “låter det bra mellan de här två låtarna?” behöver fortfarande öron. Jag gjorde därför många A/B-test med olika attack, release, gain och crossfade. Ibland såg en aggressiv inställning bättre ut på mätare men lät sämre efter tjugo minuter.

Det gjorde att jag blev försiktig med att optimera efter en enda siffra. Radio är en kedja av upplevd nivå, tonal balans och transitions. Ingen enskild mätare äger hela svaret.

Jag jagade inte bara högre nivå — jag jagade konsekvens

När jag jämförde olika låtar blev det tydligt att “så högt som möjligt” är ett dåligt mål. Jag ville att stationen skulle kännas jämn utan att slå sönder dynamiken i material som faktiskt mår bra av skillnader.

Jag testade därför attack och release i kompression, makeup gain och hur hårt limitering ska ingripa. För snabb attack kunde äta transienter. För lång release kunde få nivån att pumpa. För mycket makeup gjorde små fel i talfiler mycket tydligare.

Det var också därför voice-polish senare blev viktig. När tal går genom samma upplevda högljuddhetsmiljö förstärks kantproblem som knappt märks när filen spelas separat.

Jag har hellre en ljudkedja som är lite försiktig än en som låter imponerande i två minuter och tröttande efter en timme.

Kontrollcenteridén ändrade hur jag skrev nya funktioner

Före Kontrollcenter tänkte jag ofta “var kan jag lägga in den här fixen?”. Efter Kontrollcenter började jag fråga “vilken modul borde äga detta?”. Det är en mycket bättre fråga.

Det är exempelvis därför weather state inte ligger i promptkoden och varför Picker inte ligger i röstkedjan. Jag försöker placera regler där deras data redan finns och exponera ett enkelt resultat till nästa lager.

Kontrollcenter blev platsen där jag kunde se varför, inte bara vad

Ett vanligt radiogränssnitt visar ofta vilken låt som spelar och vad som ligger i kö. Jag ville dessutom se varför nästa beslut togs. Vilken pool valdes? Vilket showfilter var aktivt? Varför stod en skill över? Vilken talk-slot blockerade en annan?

Det gör Kontrollcenter till mer än en fjärrkontroll. Det är också ett förklaringslager. När en automatisk station beter sig konstigt är “varför” den viktigaste informationen.

Jag försöker därför få nya funktioner att lämna diagnostiska spår. En policy som returnerar false bör helst kunna ge en anledning. En scheduler som väntar ska kunna säga vad den väntar på.

Showgränsen blev en deadline som hela systemet kan se

Jag vill på sikt att Picker ska kunna väga in hur många sekunder som finns kvar till en gräns, Analyzer ska kunna ge lämpliga cue-punkter och Show Engine ska kunna börja förbereda nästa intro. Det betyder att showgränsen måste representeras som data, inte bara som ett cronjobb.

Det är ett exempel på hur en tidsregel blir mycket kraftfullare när den görs synlig för flera lager.

Jag började planera bakåt från showgränsen

En bättre lösning på exakta programstarter är inte att bli aggressiv exakt 18:00. Det är att börja fatta bättre beslut före 18:00.

Om det är sex minuter kvar kan Picker exempelvis undvika en låt som sannolikt är sju minuter lång om showen kräver en ren gräns. Om en utgående låt ändå spänner över gränsen kan Analyzer hjälpa till med en musikalisk cue-out. Samtidigt kan Show Engine förbereda handoff och intro.

Det här är fortfarande ett område jag vill utveckla mer, men tankesättet är viktigt: realtidsradio blir bättre när systemet känner till framtida deadlines.

API-designen fick också felhantering

När mobilen och webben började bero på samma endpoints behövde jag bestämma vad som händer när upstream saknas. Ska history bli tom lista? Ska now vara null? Ska hela API-anropet bli fel?

Jag föredrar strukturerade degraderingar där klienten kan skilja “ingen data just nu” från “servern dog”. Det gör UI:t bättre och felsökningen tydligare.

API:erna fick bli kontrakt i stället för genvägar

Det var lockande att bara returnera exakt det interna objektet från en tjänst. Det är snabbt när man bygger första klienten men dyrt när intern kod senare behöver ändras.

Jag började därför tänka mer på stabila publika former. Now Playing ska inte läcka interna queuefält. Request API ska returnera ett begripligt resultat och inte bara ett lågnivåfel. Appstatus ska kunna versioneras utan att mobilen måste följa varje intern refaktorering.

Det gör att jag kan skriva om Kontrollcenter betydligt friare. Klienterna har ett kontrakt med API:t, inte med implementationen bakom.

DNS och TLS gav en ny sorts väntetid

En kodändring syns direkt när processen startas om. DNS gör inte alltid det. Jag kunde få olika svar från olika resolvers under samma minut. Det gjorde att jag ibland trodde att en gatewayfix inte fungerat när jag egentligen tittade på gammal resolution.

Jag började därför skilja på konfigurationsfel och propagationsfördröjning och testa explicit mot den server jag faktiskt ville nå. Det sparar mycket frustration vid nya underdomäner.

Brandväggsreglerna blev en del av deployrutinen

När en ny tjänst skapas frågar jag numera direkt om den verkligen behöver vara nåbar utifrån. Ofta är svaret nej. Analyzer, Memory och Westin-AI behöver inte ligga publikt bara för att Web och Gateway använder dem.

Det minskar attackytan och gör arkitekturen renare. Om jag ser en extern anslutning direkt mot en intern tjänst vet jag att något kringgår tänkt väg.

Jag började även skilja tydligare på namnupplösning, certifikat och backendrouting. Alla tre kan ge symptom som ser ut som “sidan fungerar inte”, men de är helt olika felsökningsdomäner.

Hårdvarubygget blev också ett kyl- och strömprojekt

När ett kraftigt GPU-kort kör tung inferens räcker det inte att komponenten passar elektriskt. Luftflöde, fläktriktning, hubbar, headers och nätaggregat blir en del av stabiliteten. Jag fick lägga tid på hur chassifläktar matar och tömmer lådan och hur flera hubbar kan kopplas utan att överbelasta en header.

Jag har också fått se vad som händer när ett äldre nätaggregat träffar skyddet under en GPU-spik. Det är en nyttig påminnelse om att “programmet kraschade” ibland betyder “strömförsörjningen gav upp”.

Hårdvaruinköpen blev en serie praktiska kompromisser

Jag ville ha en maskin som kunde köra både språkmodell och tung röstproduktion lokalt. Det innebar att CPU, RAM, lagring, GPU och nätaggregat behövde balanseras. Jag kunde lägga alla pengar på GPU och ändå få en dålig helhet om lagringen eller kylningen blev flaskhals.

Jag valde därför en 12-kärnig processor, 32 GB arbetsminne och snabb lokal lagring som bas. Ett kraftigt 10 GB-kort fick göra den tunga GPU-delen. Jag testade samtidigt äldre kort med olika mängd videominne för att se om mer VRAM kunde väga upp lägre råprestanda.

Det gav flera praktiska lärdomar. Finjustering kan behöva mycket mer minne än inferens. Ett extra gigabyte VRAM är inte automatiskt bättre om kortet i övrigt är mycket långsammare. Flera kort kan bara hjälpa om programmet faktiskt kan dela arbetet. Och ett moderkort med många platser betyder inte att åtta GPU:er magiskt blir en enda stor accelerator.

Jag fick även bygga om luftflödet, lägga till fläkthubbar och se till att nätaggregatet klarar transienterna. Hårdvaran blev alltså en del av mjukvaruprojektet.

Containrarna gav mig en praktisk rollbackmodell

När varje tjänst har en egen image kan jag tagga den gamla innan byte. Det gör rollback mycket mer konkret. Jag behöver inte försöka återskapa exakt vilka filer som låg på disk; jag kan återgå till föregående tjänstbild och föregående konfiguration.

Det är också därför jag hellre bygger ny image än redigerar en körande container för hand. Direktpatchar är lockande klockan sent, men de skapar en verklighet som inte finns i versionsarkivet.

Den modulära installationen förändrade hur jag vågar testa

Tidigare kunde en större ändring kännas riskabel eftersom samma miljö ägde nästan allt. När Kontrollcenter, Broadcast, Analyzer och Web är separata kan jag bygga en ny Kontrollcenter-image och endast byta den tjänsten.

Om den nya versionen inte blir healthy kan jag gå tillbaka. Broadcast fortsätter under tiden med sin egen process. Den skillnaden gör att jag kan iterera mycket snabbare utan att varje experiment känns som ett fullständigt stationsunderhåll.

Jag började också ge builds tydliga versionsetiketter som berättar vilka större lager som ingår. Namnen blev ibland löjligt långa, men de gjorde felsökning lätt: jag kunde se direkt om en aktiv build innehöll tidsfix, voice smoothing, skill variation och weather memory.

Promptbantning gav både fart och bättre kvalitet

Jag såg flera gånger att Gemma 3 fick enorma mängder kontext för ett mycket litet output. Det kunde dessutom göra att de viktigaste reglerna drunknade bland mindre viktig historik.

Jag började därför vara mer aggressiv med vad varje call får se. En track link behöver inte hela stationens historia. En hourly behöver inte råa playlistkandidater. En weather-rad behöver inte alla tidigare showbeats.

Det här är lika mycket kvalitetsarbete som prestandaoptimering.

Jag började behandla tokenmängd som produktionskostnad i tid

När Gemma 3 fick stora prompts kunde jag se att mycket av väntetiden låg i input, trots att output bara var en kort radiolänk. Det var slöseri på två sätt: mer beräkning och större risk att de viktigaste instruktionerna försvinner i mängden.

Jag började därför bygga prompten per uppgift. Ett hourly behöver tid, aktuell show och relevant persona, inte hela biblioteket. Ett track link behöver aktuell och närliggande musik, inte hela schedulerhistoriken. En skill får bara de contextfält den faktiskt begärt.

Jag försöker även undvika att återberätta regler som redan kan implementeras i kod. Om weather redan filtrerats bort för att condition är oförändrad behöver prompten inte lägga hundra ord på att övertyga modellen om att inte prata om väder.

Det här gav en mycket renare relation mellan Kontrollcenter och Gemma 3: mindre kontext, tydligare uppgift, mer förutsägbart resultat.

Westin-AI måste vara förutsägbart för nästa lager

Broadcast ska inte behöva specialfall för varje röstgeneration. Därför försöker jag få Westin-AI att lämna ett konsekvent outputformat och tydliga fel. Ett timeout-fel är något annat än “motorn är nere” och något annat än “filen blev genererad men kunde inte valideras”.

Ju bättre de felen är klassificerade, desto bättre fallback kan Kontrollcenter välja.

Jag började se Westin-AI som en realtidstjänst, inte ett renderverktyg

En vanlig renderuppgift får gärna bli klar “sen”. Radio har ofta en deadline. Om en stationsident som skulle ligga mellan två specifika låtar blir färdig efter att seam redan passerat måste systemet kunna avgöra om den fortfarande är relevant.

Det innebär att Westin-AI inte bara behöver vara snabbt. Kontrollcenter behöver veta ungefär vad det kan förvänta sig. Warmupstatus, queue och timeout blir därför en del av den redaktionella logiken.

Jag vill på sikt kunna modellera uppskattad produktionstid per typ. Ett kort ident kanske kan produceras sent. Ett långt showintro behöver startas tidigare. När den informationen finns kan Show Engine planera bakåt på riktigt.

Statebuggen gjorde mig mer misstänksam mot “resume”

Resume låter alltid positivt. Men varje resume borde egentligen svara på två frågor: vilket state återställer jag och matchar det fortfarande den konfiguration som gäller nu?

Jag vill därför att fler statefiler får versionsnummer eller identitetsnycklar. Då kan en ny build aktivt avvisa gammalt state som inte längre är kompatibelt i stället för att försöka vara hjälpsam.

Jag började versionsmärka själva state-tänket

Persona-felet visade att en statefil kan vara syntaktiskt korrekt och ändå semantiskt fel. Därför vill jag att state allt oftare bär information om vilken session, show eller versionsform det hör till.

Om aktiv show inte matchar filens identitet ska state inte blint återanvändas. Om datastrukturen förändrats mellan builds ska migrering vara medveten. Det är bättre att kasta en liten mängd gammalt state än att återställa ett gammalt beslut som lyssnaren sedan hör.

Weather Memory-migreringen är ett exempel på försiktig återanvändning: jag tar bara hjälp av en nylig faktisk weather-rad och fyller condition konservativt. Jag försöker inte rekonstruera hela världen från gammal text.

Picker gav också bättre kontroll på biblioteket

När musikvalet blev kod kunde jag logga hur stor kandidatpoolen är efter varje filter. Det avslöjar exempelvis om en no-repeat-regel är för hård eller om en showfilterkombination nästan svälter poolen.

Det gör också att jag kan bygga fallbacksteg medvetet: relaxera en mjuk regel före en hård regel, aldrig tvärtom.

Picker gjorde det möjligt att mäta varför biblioteket känns tunt

Innan Picker var det svårt att veta om en tråkig period berodde på playlisten, modellen eller recencyregler. När kandidatpoolen byggs stegvis kan jag logga hur många låtar som återstår efter varje filter.

start             1842
  show_filter        612
  recent_track       544
  artist_spacing     487
  blocked            481
  weighted_selection   1

Om poolen plötsligt är tio låtar efter artist spacing vet jag att regeln är för aggressiv för den aktuella showen. Det är mycket bättre än att bara konstatera att radion “känns repetitiv”.

Det ger också möjlighet till kontrollerade fallbacknivåer. Jag kan relaxera en mjuk recencyregel innan jag någonsin rör en hård blockregel.

Tidsfraserna fick testas som matematik

Jag började behandla time-funktionen som en ren tabell som går att testa för alla sextio minuter. En formulering får inte bli falsk precis när ett band öppnar. “Några minuter efter” är exempelvis dåligt exakt på hel timme.

Den typen av minut-för-minut-test gör att språk kan verifieras nästan som logik, åtminstone inom de regler jag själv definierat.

Jag testade tidsfraserna över hela dygnet

När tidmodulen blev kod kunde jag äntligen testa den systematiskt. Jag kunde gå igenom alla timmar och minuter och se vad funktionen producerar. Det avslöjar gränsproblem som är lätta att missa när jag bara lyssnar några gånger.

Jag behövde också tänka på att fraser efter :40 ofta refererar till nästa timme. 21:53 talar om “tio”, men dagdelen ska fortfarande låta naturlig. Vid dygnsgränsen måste nästa timme normaliseras korrekt.

Det här visar en kul sak med radio: ett problem som låter språkligt blir till slut ganska ren matematik och tabelltestning.

Felet med inherit ändrade hur jag granskar arv i inställningar

Efter att låtarna slutade kapas började jag vara mer skeptisk till värden som ser neutrala ut. Ett tomt fält, noll och “inherit” kan betyda tre helt olika saker.

Jag försöker därför göra administrationsfält tydligare när jag själv kontrollerar dem. Om ett värde är ärvt ska det stå ärvt. Om noll betyder avstängt ska det framgå. Magiska värden sparar UI-yta men kostar mycket felsökning.

Latency gjorde queue-policy viktigare

Om ett klipp blir färdigt sent måste systemet avgöra om det fortfarande är relevant. Ett hourly som renderas tio minuter för sent kan inte alltid använda samma text. Ett showintro som kommer efter två låtar kanske ska kastas.

Det betyder att queue behöver förstå både ålder och typ, inte bara FIFO.

Jag började skilja generation deadline från air deadline

Det finns två tider som först såg ut som en: när text/röst måste vara färdig och när den ska höras. Om Broadcast bara kan spela ett visst segment på nästa track boundary måste renderingen vara klar före den boundaryn.

Det betyder att Kontrollcenter behöver planera med marginal. Ett klipp som blir klart två sekunder efter seam får kanske vänta fyra minuter på nästa. De två sekunderna kan alltså skapa flera minuters faktisk försening.

Det här gör prediction mycket värdefull. Jag behöver inte exakt veta hur lång nästa generering blir; jag behöver tillräckligt bra marginal för att inte missa rätt lucka.

Voice smoothing gjorde mig mer uppmärksam på hela övergången

Efter 220 ms-padding hörde jag tydligare hur mycket själva duckkurvan påverkar upplevelsen. Om musiken går ner för snabbt låter det som en av/på-knapp. Om den går ner för långsamt börjar första orden drunkna.

Jag testade därför kombinationen av padding, edge fade och längre duck i stället för att optimera varje del separat. Det är samma helkedjetänk som i nätet: en liten förbättring i tre lager kan låta mycket bättre än en extrem inställning i ett.

Jag vill att Show Engine ska kunna misslyckas snyggt

Om en plan inte kan genereras ska showen fortfarande kunna spela musik. Därför finns fallback-status. Planering är en förbättring av stationen, inte en single point of failure.

Det här är en återkommande princip: generativt innehåll får göra radion bättre men ska inte få makten att göra radion tyst.

Showplanen fick en fallback för att generativ planering aldrig ska bli ett stoppvillkor

Om planeringen misslyckas ska showen ändå kunna vara en fungerande musikshow. Därför kan episode-state markeras fallback och Broadcast fortsätter.

Jag gillar det mönstret eftersom det gör generativa funktioner additiva. De får göra stationen bättre men inte göra grundfunktionen skörare.

Samma princip gäller många skills. Nyheter, weather och faktasegment är optional. Musik är baslinjen.

Handoff lärde mig att “rendered” och “aired” måste skiljas åt

Först var det lockande att markera handoff som klar när manus och ljudfil var färdiga. Men ett renderat klipp som väntar på nästa boundary har ännu inte hänt för lyssnaren.

Det är därför state behöver separera producerat från faktiskt sänt. Samma skillnad används i Weather Memory: jag vill helst registrera senaste weather när det verkligen har nått air, inte bara när texten skapades.

Det blir extra viktigt vid restart. Kontrollcenter ska inte anta att något hördes bara för att filen fanns.

Den viktiga delen var inte vem som hade rätt först

Det intressanta med referensmodulen var att två kodbaser som utvecklats på olika håll nådde samma arkitekturella slutsats. Det är ett starkt tecken på att problemet verkligen ligger i domänen och inte bara i en specifik implementation.

För mig blev det en bekräftelse på att central arbitration var rätt investering även om den krävde mer kod än en snabb timerpatch.

Talk Scheduler fick bli ren beslutslogik

Jag ville kunna testa schedulern utan att köra Gemma 3, Westin-AI eller Broadcast. Därför byggdes själva planeringen som så ren logik som möjligt: klocka, öppna slots, senaste talk, pending state och policyresultat in; fire, wait eller miss ut.

Det gör att jag kan simulera en hel timme på millisekunder och fånga regressioner. Om jag ändrar ett fönster kan ett test visa att station-ID plötsligt kan kollidera med hourly.

Det här är ett återkommande mönster i den nyare kodbasen: separera beslut från effekt. Först bestäm vad som ska hända. Sedan kör nät, modell och queue.

Referensmodulens problem gav mig en extern kontroll på min egen arkitektur

Det är lätt att bli hemmablind i en egen kodbas. När en separat utvecklare beskriver samma problem och landar i en väldigt liknande central scheduleridé blir det ett slags oberoende validering.

Jag tog samtidigt med mig deras tydliga uppdelning mellan dispatch och policy. Det är lätt att en central scheduler växer och börjar bestämma allt. Då har jag bara flyttat monoliten. Därför vill jag behålla listenerpolicy, budget och skill-cooldowns i sina egna moduler och låta schedulern konsumera svaren.

Variation behöver också gränser

Jag vill inte ha maximal variation. Jag vill ha trovärdig variation. Om en lugn weather-rad plötsligt får samma energiska stil som ett fredagsintro har jag bara bytt monotoni mot slump.

Därför är viktningen per segmenttyp viktig. Variation sker inom en roll, inte över hela registret varje gång.

Fönster löste också ett observationsproblem

När ett segment bara får en chans är det svårt att veta om det aldrig var eligible eller bara råkade krocka. Med fönster kan loggen säga “stod över, försöker igen till :29”. Det gör beteendet begripligt medan stationen kör.

Jag försöker få samma typ av reason-codes på fler ställen. Ett automatiskt system blir mycket lättare att lita på när det kan förklara varför det inte gjorde något.

Det långsamma banter-anropet ändrade min syn på förberedelse

Före de riktigt långa genereringarna tänkte jag mest att talk ska produceras när det behövs. Efteråt blev det tydligt att tungt innehåll måste behandlas mer som förproduktion.

Show Engine vet redan vilka beats som kan komma. Det betyder att den kan börja samla kontext och värma tjänster innan exakt slot öppnar. På sikt vill jag även använda faktisk nylig latency som input till när produktionen startas.

Texture är medvetet sällsynt

Jag testade tanken mentalt åt andra hållet: om varje break har restart, skratt eller “äh” blir det snabbt uppenbart att det är en feature. Därför måste clean dominera.

Jag håller också promoformerna ännu mer sällsynta och blockerar dem över flera tidigare val. Det ska kännas som att programledaren råkade nämna sajten, inte att ett cronjobb tog över.

Jag ville ha skillnad i struktur, inte synonymroulette

En tidig idé om variation var att byta ord och formuleringar. Det gav ytliga skillnader men samma känsla. Radio Variation blev bättre först när jag började variera dramaturgin: ibland reaktion först, ibland titel först, ibland minimal backsell, ibland en liten personlig kommentar.

Jag håller dessutom minnen per dimension. Det betyder att samma ton kan återkomma även om öppningen blockeras, och tvärtom. Systemet behöver inte kasta bort en hel bra stil bara för att en del av den nyss användes.

Skills visade varför runtimevägar måste kartläggas

Det räckte inte att hitta en funktion som skapar radioprat och lägga variation där. Manuellt körda skills, schemalagda skills och automatiskt valda skills kunde gå olika vägar.

Jag fick därför kartlägga alla vägar och injicera variation på ställen där den verkligen täcker dem. Den typen av arbete är mindre synligt än en ny funktion men avgör om beteendet är konsekvent.

Weather-fixen blev ett mönster för framtida durable memory

Jag vill använda samma idé på fler saker: spara minsta nödvändiga state, skriv atomiskt och läs tillbaka vid start. Men varje minne behöver sin egen expiry. Weather från nyss kan vara relevant. Ett banterskämt från gårdagen kanske inte ska vara det.

Durable betyder därför inte permanent. Det betyder överlevande med tydlig giltighet.

Texture fick ett eget anti-repeat eftersom slump inte är minne

Även en låg sannolikhet kan ge samma val två gånger i rad. Därför räcker det inte att säga att restart bara har sju procents vikt. Jag blockerar samma icke-clean-läge direkt efter sig självt.

Promoformer har ännu bredare minne. Om sajten nyss nämnts ska den inte nämnas igen bara för att slumpen råkar vilja det.

Det här är samma grundidé som i musikvalet: sannolikhet behöver kompletteras med recencyregler.

Den lilla tidsfixen bekräftade att determinism är värd arbetet

Hade dagdelen fortfarande legat fritt i prompten hade “tio på natten” kunnat bero på modellvariation. Nu kunde jag se att det var en enda gräns i min kod. Jag ändrade den och testade funktionen.

Det är precis den typen av problem jag vill flytta från språkmodell till kod när det går.

Installern är också dokumentation

Ett bra installscript visar exakt vilka filer som förväntas finnas, vilket buildnamn som skapas och vilken service som ska startas om. På så sätt fungerar scriptet nästan som ett exekverbart förändringsdokument.

Jag försöker därför skriva ut aktiv image, backupplats och healthresultat i slutet. Det gör nästa felsökning mycket enklare.

Weather Memory blev också ett exempel på serialized writes

Om två completion-events kommer nära varandra vill jag inte att en äldre skrivning ska råka avslutas sist och skriva över nyare state. Därför serialiseras skrivningarna i en liten promise-kedja.

persistChain =
    persistChain
      .catch(ignore_previous_error)
      .then(() => atomicWrite(latestMemory))

Det är ett litet skydd men passar bra för en tjänst där flera async-flöden kan avslutas i oväntad ordning.

Grounding behöver både relevans och rätt identitet

En källa kan vara trovärdig och ändå vara fel källa för den aktuella artisten. Jag behöver därför skilja två frågor: “är den här källan generellt trovärdig?” och “handlar just den här träffen om rätt person eller verk?”.

Det gör trust-gate svårare än en domänallowlist. Jag vill kunna använda bra källor utan att ett vanligt namn råkar koppla fel person till låten.

Style-planen är medvetet enklare än textplanen

Jag vill inte att Westin-AI-style ska bli ännu en stor generativ modell. En liten viktad planner räcker långt och är lätt att förutse.

Det betyder också att jag kan ändra karaktären på en show genom vikter utan att röra själva röstmotorn. Ett kvällsblock kan exempelvis luta lite mer soft eller late-night medan ett energiskt block får fler upbeat-val.

Installerna gjorde att jag slutade vara rädd för små lokala ändringar

När backup, typkontroll, build, servicebyte och health finns i samma script blir ändringen reproducerbar. Jag behöver inte lita på att terminalhistoriken råkar finnas kvar.

Jag lägger också stor vikt vid att installern endast startar om den tjänst som verkligen behöver bytas. Om jag förändrar Kontrollcenter finns ingen anledning att samtidigt störa Broadcast eller Westin-AI.

Det minskar både risk och onödiga avbrott.

Arkitekturen idag är resultatet av många borttagna idéer

Det är lätt att se moduldiagrammet som något jag ritade först och implementerade sedan. I verkligheten är det nästan tvärtom. Gränserna har vuxit fram där jag fått problem.

Picker finns separat för att modellbaserat musikval var dyrt och otydligt. Memory finns för att processminne inte överlever restart. Talk Scheduler finns för att timers började kollidera. Gateway finns för att publik routing blev för komplex för att ligga utspridd.

Modulnamnen är därför nästan en karta över gamla problem.

Jag försöker numera optimera för nästa ombyggnad också

Jag vet efter sex år att dagens lösning inte är slutversionen. Därför försöker jag undvika att göra nya funktioner omöjliga att flytta senare.

Ett tydligt API, ett litet stateformat och en pure planner är lättare att ersätta än ett djupt specialfall inne i en stor process. Jag kommer säkert göra om delar igen. Skillnaden är att jag vill att nästa omtag ska vara ett kontrollerat byte, inte en total rivning.

Det är kanske den största mognaden i projektet: jag bygger inte längre som om varje beslut måste leva för alltid.